Sustainable and intelligent management of energy for smarter railway systems in Europe: an integrated optimization approach

Transcription

1 Sustainable and intelligent management of energy for smarter railway systems in Europe: an integrated optimization approach D7.4 - Proposal for Technical Recommendation - Energy and power related information protocols at operational level Due date of deliverable: 31/12/2015 Actual submission date: 08/12/2015 Leader of this Deliverable: UIC Reviewed: Y Document status Revision Date Description 1 20/08/2015 First draft circulated 2 01/09/2015 Second draft circulated 3 09/11/2015 Third draft circulated 4 13/11/2015 Fourth draft circulated 5 20/11/2015 Fifth draft circulated 6 27/11/2015 Sixth draft circulated 7 Final issue MRL-WP7- - Page 1 of 50 08/12/2015

2 Project co-funded by the European Commission within the Seven Framework Programme ( ) Dissemination Level PU Public x PP RE CO Restricted to other programme participants (including the Commission Services) Restricted to a group specified by the consortium (including the Commission Services) Confidential, only for members of the consortium (including the Commission Services) Start date of project: 01/10/2012 Duration: 39 months MRL-WP7- - Page 2 of 50 08/12/2015

3 EXECUTIVE SUMMARY In order to response to the need to have a better and more standardized integrated energy management, MERLIN partners have planned to prepare a proposal for Technical Recommendation which will serve, following the submission to the UNIFE/UIC SSG, as an input for the standardisation work of European Standardisation bodies such as CEN/CENELEC. This deliverable will identify which information protocols at operational level should be collected in order to achieve an integrated energy management. Accurate energy consumption information will enable RUs and IMs together with MERLIN developments to measure/collect data on energy flows and help them decide on what components of the infrastructure grid to intervene in order to have better usage of energy/energy savings. The proposal will consider architecture of the REM-S, including the Information and Communication layers. Executive Summary Scope Normative references Terms, definitions and abbreviations General operational REM-S reference architecture Concept description REM-S Actors Communication Layer EBDM-GOS External entities - EBDM RU Server - GOS EC-DER - GOS IM Server - GOS GOS - LOS DOEM-LOS DOEM-IM server Information Layer DOEM-LOS DOEM-IM Server RU Server - GOS EC-DER - GOS IM Server - GOS EBDM-GOS MRL-WP7- - Page 3 of 50 08/12/2015

4 4.4.7 GOS - LOS LOS-LOS Figures Figure 1: Smart Grid Architecture Model (SGAM)... 8 Figure 2: SGAM Plane Figure 3: REM-S Concept Figure 4: REM-S Functions and Operational Modes Figure 5: REM-S concept with several LOS Figure 6: Business Case Overview of the REM-S Figure 7: High Level Use Case: DAO Figure 8: High Level Use Case: MAO Figure 9: High Level Use Case: RTO Figure 10: DOEM LOS Architecture Diagram Figure 11: Linking sequence diagram Figure 12: MAO sequence diagram Figure 13: Report sequence diagram Figure 14: Unlink sequence diagram Figure 15: DOEM ATO/IM Architecture Diagram Figure 16: DOEM TCC Architecture Diagram Figure 17: Speed limitations sequence diagram Figure 18: Timetable update sequence diagram MRL-WP7- - Page 4 of 50 08/12/2015

5 Foreword This MERLIN document (Proposal of TecRec Energy and power related information protocols at operational level) has been prepared by a Working Group involving: UNIFE, UIC, ADIF, Alstom, Ansaldo STS, CAF, D Appolonia, FFE, RFF, RENFE, MerMec, Oltis, Ansaldo Breda, Network Rail, Trafikverket and Siemens. The content of this document has been prepared as a result of the outcomes of the EU funded project MERLIN Sustainable and intelligent management of energy for smarter railway systems in Europe: an integrated optimisation approach. The project partners involved have put forward the deliverable D7.4 included in Work Package 7 to UIC and UNIFE for its submission to the UNIFE/UIC SSG as a proposal of TecRec. TecRecs are managed by a joint UIC/UNIFE standards management group that meets on a regular basis to coordinate the process. TecRecs can be downloaded by UNIFE and UIC members from the two organisations websites: and Introduction This document is a deliverable (D7.4) of the EU founded project MERLIN and represents a draft proposal for TecRec. Copyright Copyright to this document is owned by all MERLIN partners. All rights are hereby reserved. MRL-WP7- - Page 5 of 50 08/12/2015

6 1 SCOPE In order to response to the need to have a better and more standardized integrated energy management, MERLIN partners have planned to prepare a proposal for Technical Recommendation which will serve, following the elaboration by the UIC-UNIFE Standardisation Steering Group, as an input for the standardisation work of European Standardisation bodies such as CEN/CENELEC. This deliverable will identify which information protocols at operational level should be collected in order to achieve an integrated energy management. Accurate energy consumption information will enable RUs and IMs together with MERLIN developments to measure/collect data on energy flows and help them decide on what components of the infrastructure grid to intervene in order to have better usage of energy/energy savings. The proposal will consider architecture of the REM-S, including the Information and Communication layers. 2 NORMATIVE REFERENCES The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. IEC /TASE.2: - Telecontrol equipment and systems Part 6/TASE.2: Protocol Definition IEC : Communication networks and systems for power utility automation - Part 7-420: Basic communication structure - Distributed energy resources logical nodes IEC : Telecontrol equipment and systems - Part 5-101: Transmission protocols - Companion standard for basic telecontrol tasks IEC : Telecontrol equipment and systems - Part 5-104: Transmission protocols - Network access for IEC using standard transport profiles IEC Electronic railway equipment - Train communication network (TCN) IEC : Electronic railway equipment - Train communication network (TCN) - Part 2-6: On-board to Ground Communication 3 TERMS, DEFINITIONS AND ABBREVIATIONS For the purposes of this document, the following terms and definitions apply. 3.1 CEN Comité Européen de Normalisation MRL-WP7- - Page 6 of 50 08/12/2015

7 3.2 DAO Dynamic Onboard Energy Manager 3.3 EPP Electricity Procurement Planner 3.4 ETSI European Telecommunications Standards Institute 3.5 ETSI European Telecommunications Standards Institute 3.6 IEC International Electrotechnical Commission 3.7 LOS Local Optimisation System 3.8 MAO Minutes Ahead Optimisation 3.9 Open Automated Demand Response (OpenADR) is defined as a fully automated demand response using open standard, platform-independent and transparent end-to-end technologies or software systems. The adoption of OpenADR to the smart grid is very important to provide effective deployment of dynamic pricing, demand response, and grid reliability. It is an open and standardized way for electricity providers and system operators to communicate demand response signals with each other and with their customers using a common language over any existing IPbased communications network, such as the Internet PCC Point of Common Coupling 3.11 REM-S Railway Energy Management System 3.12 RTO Real Time Operation 3.13 SGAM Smart Grid Architecture Model MRL-WP7- - Page 7 of 50 08/12/2015

8 4 GENERAL OPERATIONAL REM-S REFERENCE ARCHITECTURE 4.1 CONCEPT DESCRIPTION This section describes the general concept behind the architecture of the Railway Energy Management System (REM-S), providing an overview of how the system has been built and the reference models followed. The detailed architecture of the system is also described. The Railway Energy Management System is an integrated solution aiming at achieving a more sustainable and optimised energy usage in European electric mainline railway systems. This can be obtained through a system monitoring the energy consumptions of the different subsystems of the railway network and their components and suggesting a smart solution for the optimisation of use of energy in the different parts of the system. Because of the distributed nature of the railway system, the system size, complexity and uncertainties, as well as the dynamic and moving nature of the loads, the energy management system can be based on dividing the railway system into different local areas (zones). At least one intelligent substation should be present in each zone, acting as interface for the zone entities. Hence, it should be able to communicate to the other local entities, to the intelligent substations of neighbouring zones and to the Control Centre, and through it to electricity market The Smart Grid Architecture Model (SGAM) The architecture of the system has been developed according to the Smart Grid Architecture Model (SGAM), i.e. a reference model of smart grid architectures for different sectors of application issued by the CEN - CENELEC - ETSI Smart Grid Coordination Group and consists in the optimisation of the energy flow through the railway system at different levels. The Smart Grid Architecture Model (SGAM) is a three dimensional model, merging the dimension of five interoperability layers with two dimensions of the Smart Grid Plane, as shown in Figure 1. Figure 1: Smart Grid Architecture Model (SGAM) MRL-WP7- - Page 8 of 50 08/12/2015

9 The Smart Grid Plane is made up of Zones - representing the hierarchical levels of power system management (Process, Field, Station, Operation, Enterprise and Market) and Domains covering the complete electrical energy conversion chain: Bulk Generation, Transmission, Distribution, Distributed Energy Resources and Customers Premises. The five interoperability layers (Business, Function, Information, Communication and Component) cover the whole Plane representing the third dimension of the Smart Grid model. In order to allow a clear presentation of the architecture model, different interoperability layers are specified, as shown in Table 1. Layer Business Function Component Information Communication Description Represents the business view on the information exchange related to smart grids. SGAM can be used to map regulatory and economic (market) structures and policies, business models, business portfolios (products & services) of market parties involved. Also business capabilities and business processes can be represented in this layer. Describes functions and services including their relationships from an architectural viewpoint. The functions are represented independent from actors and physical implementations in applications, systems and components. The functions are derived by extracting the use case functionality which is independent from actors. The physical distribution of all participating components in the smart grid context. This includes system actors, applications, power system equipment (typically located at process and field level), protection and telecontrol devices, network infrastructure (wired / wireless communication connections, routers, switches, servers) and any kind of computers. Describes the information that is being used and exchanged between functions, services and components. It contains information objects and the underlying canonical data models. These information objects and canonical data models represent the common semantics for functions and services in order to allow an interoperable information exchange via communication means. To describe protocols and mechanisms for the interoperable exchange of information between components in the context of the underlying use case, function or service and related information objects or data models. Table 1: SGAM Interoperability Layers The power system can be represented by physical domains of the electrical energy conversion chain and hierarchical zones for the management of the electrical process; this is represented through the SGAM plane, as shown in Figure 2. MRL-WP7- - Page 9 of 50 08/12/2015

10 Figure 2: SGAM Plane The Smart Grid Plane covers the complete electrical energy conversion chain. Table 2 lists and describes the SGAM domains. Domain Bulk Generation Transmission Distribution DER Customer Premises Description Representing generation of electrical energy in bulk quantities, such as by fossil, nuclear and hydro power plants, off-shore wind farms, large scale solar power plant (i.e. PV, CSP) typically connected to the transmission system Representing the infrastructure and organisation which transports electricity over long distances Representing the infrastructure and organisation which distributes electricity to customers Representing distributed electrical resources directly connected to the public distribution grid, applying mall-scale power generation technologies (typically in the range of 3kW to kW).These distributed electrical resources may be directly controlled by DSO Hosting both- end users of electricity, also producers of electricity. The premises include industrial, commercial and home facilities (e.g. chemical plants, airports, harbours, shopping centres, homes). Also generation in form of e.g. photovoltaic generation, electric vehicles storage, batteries, micro turbines are hosted Table 2: SGAM Domains In Table 3 the definition of zones is provided. The zones reflect a hierarchical model considering the concept of aggregation and functional separation in power system management. MRL-WP7- - Page 10 of 50 08/12/2015

11 Zone Process Field Station Operation Enterprise Market Description Including the physical, chemical or spatial transformations of energy (electricity, solar, heat, water, wind ) and the physical equipment directly involved.(e.g. generators, transformers, circuit breakers, overhead lines, cables, electrical loads any kind of sensors and actuators which are part or directly connected to the process, ). Including equipment to protect, control and monitor the process of the power system, e.g. protection relays, bay controller, any kind of intelligent electronic devices which acquire and use process data from the power system. Representing the areal aggregation level for field level, e.g. for data concentration, functional aggregation, substation automation, local SCADA systems, plant supervision Hosting power system control operation in the respective domain, e.g. Distribution Management Systems (DMS), Energy Management Systems (EMS) in generation and transmission systems, microgrid management systems, virtual power plant management systems (aggregating several DER), Electric Vehicle (EV) fleet charging management systems. Includes commercial and organisational processes, services and infrastructures for enterprises (utilities, service providers, energy traders ), e.g. asset management, logistics, work force management, staff training, customer relation management, billing and procurement Reflecting the market operations possible along the energy conversion chain, e.g. energy trading, mass market, retail market SGAM and REM-S Architecture Table 3: SGAM Zones The five layers defined in the SGAM have been identified in the REM-S architecture. Specifically, Information Layer and Communication Layer are considered in the scope of this proposal for TecRec. Information Layer should consist in the data model and takes into account smart grid standards that are compatible with railway standards. Communication Layer is composed by smart grid applications communication standards that can be applied to the railway domain Figure 3 represents the general architecture of the REM-S and highlights the different levels of optimisation, i.e. the three corresponding operational modes : Day Ahead Optimisation (DAO), Minute Ahead Optimisation (MAO) and Real Time Operation (RTO). On top of the diagram, the link to the electricity market is represented. This is performed by the EBDM, i.e. a module of the REM-S that determines the best way to purchase/sell the energy consumed/generated by the railway system managed by the REM-S. MRL-WP7- - Page 11 of 50 08/12/2015

12 Electricity Market Day Ahead Optimisation Control Center DAO Optimisation Minute Ahead Optimisation MAO Optimisation Real Time Operation Dynamic Onboard Energy Manager Local energy source Operation Control, Actions Implementation and Optimisation Substation 1 Substation n Wayside Energy Storage External Consumer Energy Flow.. Figure 3: REM-S Concept The Energy Buyer Decision Maker helps determining the best way of combining the available contracts with the participation in the spot markets to optimize the price of the energy. The EBDM module uses as an input a list of constraints supplied by an external Electricity Procurement Planner (EPP) (bidding strategy, long term constrains for the bidding ). The Electrical Market Forecast Provider sends to the EBDM information regarding market prices previsions, behaviour of future sessions of the electricity market. The zones (i.e. the intelligent substation) receive the day-ahead global optimisation plan from the Control Centre and implement it in their own area, locally accommodating unanticipated mismatches. As neighbouring zones are in contact, they can coordinate and resolve border issues about energy and power optimisation, like providing mutual support in case of variation of power demands and coordinating transition of trains. Multi-Agent System (MAS) technology is applied for implementing energy management system in the zones. Given that the generic load railway system interacts with the larger power system (public grid) and its market (electricity market), it makes sense to adopt a similar time structure for the energy optimisation, yielding three operational modes: The main aim of the Day Ahead Optimisation (DAO) is to calculate the optimum behaviour of the network for the next 24/48 hours horizon; it is usually done once a day or when the MAO asks for a recalculation (due to a big deviation not solved in the Minutes Ahead Optimisation) but the periodicity of the calculation is configurable. DAO is performed by the component Global Optimisation System (GOS); the GOS is an intelligent module responsible for making a plan for the next 24/48 depending to the forecasted energy profiles, in order to optimise energy consumption, power demand and cost in the whole system. The main output of this application, i.e. the optimised day ahead power profile per subnetwork is sent to the component Local Optimisation Application (LOS). MRL-WP7- - Page 12 of 50 08/12/2015

13 MAO is a minutes ahead optimisation process, performed by the LOS; the main aim of this process is to follow the optimised 24 hours ahead power profile per sub-network coming from the DAO throughout the next minutes. The time interval considered in MERLIN for the Minutes Ahead Optimisation is 15 minutes, but this periodicity can be configured differently. The optimisation process is usually done every 15 minutes or when there is a deviation between the forecasted and the real behaviour of the system during the 15 minutes process that cannot be solved by the RTO control. Local Optimisation System is responsible for making the plan for the next 15 minutes depending to the real time measuring results and forecasted energy profiles, in order to follow the global energy consumption plan of the system and optimise energy consumption and power demand at its own local area. The main aim of the Real Time Operation is to fulfil the calculated MAO profiles for the subnetwork (optimised sub-network 15 minutes or the remaining of 15 minutes power profile), taking into account the real time status and behaviour of all the components of the sub-network, as well as the surpluses and needs of the adjacent sub-networks. Figure 4 below represents the functions of the different operational modes above described and their implementation along the timeline. data trigger First 24 hrs - 15 mins 15 mins 15 mins 24 hrs... DAO Optimisation DAO Energy trading Billing MAO MAO Optimisation MAO Optimisation MAO Optimisation Real Time Data Acquisition Estimation for MAO Estimation for MAO Estimation for MAO RTO Operation Control Action Implementation & Optimisation Figure 4: REM-S Functions and Operational Modes Figure 5 depicts the energy management concept with the three modes of operation in time and location. In this architecture DAO runs a Global EMS (Energy Management System) for the whole railway network yielding energy, power or cost optimisation with a top-bottom approach based on train timetables and power estimation profiles, railway distribution network characteristics, Distributed Energy Resources estimated generation and External Consumers power estimated demand. In Minutes Ahead time slices, Local EMSs executed in each zone optimizes power profiles locally with the target of following Global EMS plan. The Local EMS is done by MRL-WP7- - Page 13 of 50 08/12/2015

14 coordinating resources to address fast, unanticipated occurrences, such as use of regenerated energy from trains, surplus energy stored in Energy Storage Systems (ESSs) or request of more energy for a train which is delayed. This level of optimisation is the link between centralized EMS and the Real Time Operation in all zone agents. Solving one centralized optimisation problem for the short term flexibilities in the massive railway system is unfeasible, while applying the MAS approach with Local EMS, the short term (Minutes Ahead) optimisation is achievable. Electricity Market Day Ahead Optimisation Min-Ahead Optimisation Control Center Global EMS Local EMS 1 Local EMS 2 Local EMS n Real-Time Operator 1 Real-Time Operator 2 Real-Time Operator n... Real Time Operation DOEM DER ISST... SST n ISST... RSST n ESS ISST... SST n Energy Flow.. EC Figure 5: REM-S concept with several LOS The Business Case Overview The Business case depicted in Figure 6 presents a general overview of the Business Actors of the system, their assigned Business Goals (represented with green rectangles) and the Business Cases (represented with yellow eclipses) performed by the Business Actors in order to reach the individual Business Goals. Each of the Business Cases is further detailed through the High Level Use Cases (represented with blue eclipses), which represents the high level functions of the REM- S. MRL-WP7- - Page 14 of 50 08/12/2015

15 Figure 6: Business Case Overview of the REM-S In the following figures are represented in detail, the SGAM diagrams of the high level functions of the REM-S. With green ellipses, are represented the communication protocols used to exchange information components. Figure 7 represents the DAO high level use case, Figure 8 MAO high level use case and Figure 9 RTO high level use case. MRL-WP7- - Page 15 of 50 08/12/2015

16 Figure 7: High Level Use Case: DAO Figure 8: High Level Use Case: MAO MRL-WP7- - Page 16 of 50 08/12/2015

17 Figure 9: High Level Use Case: RTO 4.2 REM-S ACTORS The business model proposed for the REM-S includes some main business actors, contributing to implement the overall optimisation of energy flows in the railway system. The actors part of the system are presented in this section. The different actors have relationships among themselves through the business use cases above described. The operational Railway Energy Management System should collaborate with internal and external partners, and carry out the optimization measures. REM-S includes wayside and onboard parts. Specifically, on wayside, the global and local optimisation should be carried out and interfaces with the energy market are implemented; on-board, the indications received from on ground optimisation are applied. The main business actors of the REM-S are described in the following. The Electricity Market Operator represents any company in charge of all the operations required for the electricity market operation (receiving the purchasing/selling bids, matching process, billing.). MRL-WP7- - Page 17 of 50 08/12/2015

18 The Electrical System Operator role in a wholesale electricity market is to manage the security of the power system in real time and co-ordinate the supply of and demand for electricity, in a manner that avoids fluctuations in frequency or interruptions of supply. The Grid Owner acts as Transmission System Operator (TSO) and Distribution System Operator (DSO). TSO is an entity entrusted with transporting energy in the form of electrical power on a national or regional level, using fixed infrastructure. DSO is responsible for operating, ensuring the maintenance of and, if necessary, developing the distribution system in a given area and, where applicable, its interconnections with other systems and for ensuring the long term ability of the system to meet reasonable demands for the distribution of electricity. Infrastructure Manager (IM) means any body or firm responsible in particular for establishing, managing and maintaining railway infrastructure, including traffic management and controlcommand and signalling; the functions of the Infrastructure Manager on a network or part of a network may be allocated to different bodies or firms. Railway Operator means any public or private undertaking licensed according to the "Directive 2012/34/EU of the European Parliament and of the Council," Official Journal of the European Union, European Union, 2012., whose principal business is to provide services for the transport of goods and/or passengers by rail with a requirement that the undertaking ensure traction; this also includes undertakings which provide traction only. It may possess the rolling stocks and it is authorized with the access to the railway infrastructure. An Energy Supplier refers to a party that supplies the customers or the market with electricity, and receives profits from the energy trading activities. 4.3 COMMUNICATION LAYER EBDM-GOS The information exchanged and the communication protocols between EBDM and GOS have been defined in the following table: EBDM-GOS GOS OUTPUT Energy required at each PCC PROTOCOL IEC /TASE.2 GOS INPUT Estimated average price of energy for each hour and PCC Price variations and warnings Not scheduled electricity open sessions PROTOCOL OpenADR OpenADR Customised protocol MRL-WP7- - Page 18 of 50 08/12/2015

19 For each input/output a description of the information exchanged has been defined in External entities - EBDM The inputs provided by external entities to the EBDM are defined in the following table: SOURCE INTPUT PROTOCOL Forecast provider EMO/ESO EMO EPP EPP ESO/TSO/DSO Forecast of the estimated behaviour of the electricity markets Not scheduled electricity sessions Final prices and energy accepted to be sold/purchased Contractual arrangement constraints (1-2 days horizon) Bidding estrategy Other costs Custom (each provider has its own). Optionally, CIM may be used, but some tweak may be required. Custom (each EMO has its own). Optionally, CIM may be used, but some tweak may be required. Custom (each EPP has its own). Custom (each TSO/DSO has its own). Optionally, CIM may be used, but some tweak may be required. SOURCE OUTPUT PROTOCOL EBDM EBDM Bids to be sent to each session of the Electricity Market Information of the energy bought by means of the contractual agreement required by the ESO/TSO/DSO Custom (each EMO has its own). Optionally, CIM may be used, but some tweak may be required. For each input a description of the information exchanged has been defined in the following tables: Forecast Provider_EBDM_Forecast of the estimated behaviour of the electricity Forecast Provider EBDM markets Attribute Type Description session Text Identification of the market session hours Text Identification of the hours covered by each session scenario Text Identification of of the scenario probability Number Probability of the scenario occurence price estimation Number Estimated price of the energy for each seesion, hour, scenario and probability EMO_EBDM_Final prices and energy acceoted to be sold/purchased EMO EBDM MRL-WP7- - Page 19 of 50 08/12/2015

20 Attribute Type Description hours Text Identification of the hours covered by each session blocks Text Identification of the amount of energy to be sold/purchased in the market session energy (MWh) Number Energy to be sold/purchased in the market session price (EUR/MWh) Number Price of the energy to be sold/purchased in the market session The information included in the above table is the basic information required by the EBDM coming from the EMO. However, according to the specification provided by the EMO, more information (inputs) may be exchanged EPP_EBDM_Contractual arrangement EPP EBDM constraints (1-2 days horizon) Attribute Type Description Id Text Identification of the contractual arrangement Hour Group Text Identification of the hourly period covered by each contractual arrangement Applied Text Defines if the constraint is applied to the hours individually or not Min. Energy [MWh] Number Minimum energy required Max. Energy [MWh] Number Maximum energy required Price [EUR/MWh] Number Price of the energy All/Nothing condition Text Defines if the available energy is divisible or not in smaller blocks Hour Text Specifies the hours covered by each session EPP_EBDM_Bidding estrategy EPP EBDM Attribute Type Description Hour Text Identification of the hours covered by each session Energy (percentile) Number Percentage of the energy to be sold/purchased in the spot market Price (EUR/MWh) Number Price of the energy to be sold/purchased in the spot market ESO/TSO/DSO_EBDM_Other costs ESO/TSO/DSO EBDM Attribute Type Description MRL-WP7- - Page 20 of 50 08/12/2015

21 Hour Text Identification of the hours covered by each session PCC Text Identification of the PCC Fixed costs Number Operation costs for each PCC and each hour EBDM_Electricity Market_Bids to be sent EBDM EM to each session of the EM Attribute Type Description hour Text Specifies the hours covered by each session blocks Text Amount of energy to be sold/purchased in the market session energy (MWh) Number Energy to be sold/purchased price (EUR/MWh) Number Price of the energy to be sold/purchased The information included in the above table is the basic information required by the EBDM coming from the ESO/TSO/DSO. However, each EMO has its own formats and usually more information is requested. EBDM_ESO/TSO/DSO_Information of the energy bought by means of the EBDM ESO/TSO/DSO contractual agreement Attribute Type Description hour Text Identification of the hours covered by each session energy Number Energy bought by means of the contractual agreement contracts Text Identification of the contractual arrangement RU Server - GOS The inputs provided by Railway Undertaking to the Day Ahead Optimisation should be exchanged through the following protocol: Source Input Protocol Railway Undertaking Forecasted power profile Railway Undertaking Contractual arrangement of energy supplier with RU Customised protocol Customised protocol The DAO Output sent to RU should be exchanged through a customised protocol. MRL-WP7- - Page 21 of 50 08/12/2015

22 4.3.4 EC-DER - GOS The inputs provided by External Consumers to the DAO should be exchanged through Open Automated Demadn Response (OpenADR). The The inputs provided by distributed electrical resources to the DAO should be exchanged through the protocol IEC IM Server - GOS The inputs provided by the Infrastructure Manager to the Day Ahead Optimisation should be exchanged through the following protocols: Network configuration: IEC /104; Real timetable: TCP/IP, TIBCO channel; Real time status of the network: IEC ; Real time consumption restrictions per feeding sections IEC ; Expected train composition: TCP/IP, TIBCO channel GOS - LOS Information between Day Ahead Optimisation and Minutes Ahead Optimisation (LOS) should be exchanged through the following protocols. DAO trigger (from Minutes Ahead Optimisation to Day Ahead Optimisation): IEC /TASE.2. Power required at each PCC divided in block of given likelihood, for each hour (from DAO Optimisation of power, energy and price to MAO Optimisation of energy and power ): IEC /TASE DOEM-LOS Standard IEC is proposed for data exchange between vehicles (DOEM) and ground (LOS). The application interface between these components is proposed in Information layer chapter via the communication connection using the IEC DOEM-IM server The communication between DOEM and IM server needs to be standardised for interoperability issues. However, the definition of the standard to be used is out of scope of this document, as it is operational related topic and different expert bodies are discussing the best standard in other forums. MRL-WP7- - Page 22 of 50 08/12/2015

23 4.4 INFORMATION LAYER DOEM-LOS The following functional modules are identified for the exchange of information between LOS (ground device) and DOEM (onboard device). This chapter does not propose the standardisation of neither the functions themselves, which are responsible in the individual vehicles or wayside components, nor the design and arrangement of the control equipment, but only the application interface between the vehicles (DOEM) and ground (LOS) via the communication connection using the IEC For interoperability issues, the following exchange of data should be standardised. cmp DOEM-LOS Components DOEM LOS FI_DOEM_LOS_Link F_DOEM_Link F_LOS_Link FI_LOS_MAO_Request F_DOEM_MAO F_LOS_MAO FI_DOEM_MAO_Calculation FI_DOEM_LOS_Report F_DOEM_Report F_LOS_Report FI_DOEM_LOS_Unlink F_DOEM_Unlink F_LOS_Unlink Figure 10: DOEM LOS Architecture Diagram Linking function DOEM should establish a connection with the LOS when the train enters its area of control. Areas of control (borders) and LOS addresses should be defined in the onboard infrastructure description file, using RailML, which can also be dynamically updated from ground using other service not described in this document. DOEM should also update the connection if there is a change in one of the fields (e.g. TrainMode). The LOS may take into account or not the vehicle in the energy management process depending on to its mode. For example, if the train is under commissioning, the LOS should know that MRL-WP7- - Page 23 of 50 08/12/2015

24 perhaps the consumption estimation will be not reliable and that the train probably might not be able to take part in the negotiation phase. sd DOEM-LOS Model DOEM LOS Hello() Acknowledge() Figure 11: Linking sequence diagram FI_DOEM_LOS_Link::Hello Table 4 proposes Hello message exchange in XML Schema Definition Language. For a better understanding, an example is added. XMLelement_ FI_DOEM_LOS_LINK_Hello DOEM LOS Attribute Type Description serviceid TrainRouteID Train service identification engineid EngineID Train engine identification timestamp Time Actual time UTC sectionid LandmarkID Current track section Position TrainPos Train position (m) from the beginning of SectionID operatorcode unsignedbyte 0 = Default 71 = RENFE 80 = DB 81 = ÖBB 83 = FS 85 = SBB 87 = SNCF 88 = SNCB generaltrainmode unsignedbyte General target state of the train: MRL-WP7- - Page 24 of 50 08/12/2015

25 trainmode TrainMode Main state of the train This state influences authorizations in order to allow changes to be made on the system. The loading of software and forcing of signals is only allowed in Status 3. It applies the entire train. 0 = None 1 = Operation 2 = Maintenance 3 = Commissioning 4 = Automatic-Operation trainsubmode unsignedbyte The following substate of the train from an operator's perspective depends on the main state: Shutdown Mode 0 = None 1 = Parking Mode 2 = Pulled Mode in Service Mode 0 = None 1 = Battery Power Supply 2 = Depot Power Supply 3 = Catenary Power Supply 4 = Train Prepared Driving Mode 0 = None 1 = Normal Mode 2 = Transition Mode 3 = Washing Mode 4 = Coupling Mode 5 = Shunting Mode DOEM_SW_Version unsignedbyte Version number of DOEM software DOEM_SW_Subversion unsignedbyte Subversion number of DOEM software XSD <xs:element name= FI_DOEM_LOS_LINK_Hello > <xs:complextype> <xs:attribute name= serviceid type= xs:trainrouteid use= required /> <xs:attribute name= engineid type= xs:engineid use= required /> <xs:attribute name= timestamp type= xs:time use= required <xs:attribute name= sectionid type= xs:landmarkid use= required /> <xs:attribute name= position type= xs:trainpos use= required /> MRL-WP7- - Page 25 of 50 08/12/2015

26 <xs:attribute name= operatorcode type= xs:unsignedbyte use= required /> <xs:attribute name= gentrainmode use= required > <xs:simpletype> <xs:restriction base= xs:unsignedbyte > <xs:enumeration value= 0 /> <xs:enumeration value= 1 /> <xs:enumeration value= 2 /> <xs:enumeration value= 3 /> <xs:enumeration value= 4 /> </xs:restriction> </xs:simpletype> </xs:attribute> <xs:attribute ref= trainmode use= required /> <xs:attribute name= trainsubmode use= required > <xs:simpletype> <xs:restriction base = xs:unsignedbyte > <xs:enumeration value = 0 /> <xs:enumeration value = 1 /> <xs:enumeration value = 2 /> <xs:enumeration value = 3 /> <xs:enumeration value = 4 /> <xs:enumeration value = 5 /> </xs:restriction> </xs:simpletype> </xs:attribute> <xs:attribute name= DOEM_SW_Version type= xs:unsignedbyte use= required /> <xs:attribute name= DOEM_SW_Subversion type= xs:unsignedbyte </xs:complextype> </xs:element> use= required /> Example <FI_DOEM_LOS_LINK_Hello serviceid= 128 engineid= 2478 timestamp= T15:16: sectionid= 0001 position= operatorcode= 71 generaltrainmode = 4 trainmode= 2 trainsubmode= 1 DOEM_SW_Version= 2 DOEM_SW_Subversion= 1 /> Table 4. FI_DOEM_LOS_Link::Hello message XML description MRL-WP7- - Page 26 of 50 08/12/2015

27 FI_DOEM_LOS_Link::Acknowledge Table 5 proposes Hello- Acknowledge message exchange in XML Schema Definition Language. For a better understanding, an example is added. XMLelement_ FI_DOEM_LOS_LINK_Acknowledge LOS DOEM Attribute Type Description timestamp Time Actual time UTC LOSStatus unsignedshort LOS acknowledges the Hello message returning one of the following values: 0 = Unknown error 1 = Link established successfully 2 = LOS not operational 4 = Service not available 6 = SW versions not compatible 8 = Train out of control area / wrong LOS heartbeatrate unsignedshort Indicates the period of time in seconds after which the DOEM has to report LOS about its status periodically as life sign or heartbeat. Value 0 or 0xFFFF means no need for reporting. XSD <xs:element name= FI_DOEM_LOS_LINK_Acknowledge > <xs:complextype> <xs:attribute name= timestamp type= xs:time use= required /> <xs:attribute name= LOSStatus use= required > <xs:simpletype> <xs:restriction base = xs:unsignedshort use= required > <xs:enumeration value = 0 /> <xs:enumeration value = 1 /> <xs:enumeration value = 2 /> <xs:enumeration value = 4 /> <xs:enumeration value = 6 /> <xs:enumeration value = 8 /> </xs:restriction> </xs:simpletype> </xs:attribute> <xs:attribute name= heartbeatrate type= xs:unsignedbyte use= required /> </xs:complextype> MRL-WP7- - Page 27 of 50 08/12/2015

28 </xs:element> Example <FI_DOEM_LOS_LINK_Acknowledge timestamp= T15:16: LOSStatus = 1 heartbeatrate = 0 /> Table 5. FI_DOEM_LOS_Link::Acknowledge message XML description MAO function Every certain time LOS starts a negotiation with other agents involved in the energy management system to carry out the Minutes Ahead Optimisation (MAO). For each iteration LOS may request DOEM to forecast and send the power consumption profile in a certain period of time according to the current conditions and constraints (including power or energy limits). sd DOEM-LOS MAO DOEM LOS MAO_Request() MAO_Reply() MAO_Request() MAO_Reply() FI_DOEM_LOS_MAO_Request Figure 12: MAO sequence diagram Table 6 proposes MAO Request message exchange in XML Schema Definition Language. For a better understanding, an example is added. XMLelement_ FI_DOEM_LOS_MAO_Request LOS DOEM Attribute Type Description timestamp Time Actual time UTC MAO_Start_Time Time UTC from which the energy consumption profile shall be forecasted. MRL-WP7- - Page 28 of 50 08/12/2015

29 MAO_Start_Time > timestamp. MAO_Duration unsignedbyte Length of forecast in minutes MAO_Timeslice unsignedbyte Step duration in seconds for which average power consumption shall be reported. The number of reported points shall be (MAO_Duration x 60) / MAO_Timeslice. MAO_Timeslice shall be in the range [1,120] seconds. If MAO_Timeslice is equal to zero then one single timeslice lasting the complete MAO_Duration will be used. MAO_Id MAOID Identification of the MAO process MAO_N_Limitations unsignedbyte Number of limitations included MAO_Limitation MAO_Limitations Power and energy limitations for MAO calculation. As many MAO_limitations as MAO_N_Limitations states. XSD <xs:element name="fi_doem_los_mao_request"> <xs:complextype> <xs:sequence> <xs:element ref="mao_limitation" minoccurs="1" maxoccurs="unbounded"/> </xs:sequence> <xs:attribute name="timestamp" type="xs:time" use="required"/> <xs:attribute name="mao_start_time" type="xs:time" use="required"/> <xs:attribute name="mao_duration" type="xs:unsignedbyte" use="required"/> <xs:attribute name="mao_timeslice" type="xs:unsignedbyte" use="required"/> <xs:attribute name="mao_id" type="xs:maoid" use="required"/> <xs:attribute name="mao_n_limitations" type="xs:unsignedbyte" use="required"/> </xs:complextype> </xs:element> Example <FI_DOEM_LOS_MAO_Request <MAO_Limitation> <limit_start_location> <sectionid="0001"/> <position="1524"/> </limit_start_location> <limit_end_location> timestamp=" t15:16:30.000" MAO_Start_Time =" T15:20:00.000" MAO_Duration ="1" MAO_Timeslice="10" MAO_Id="214" MAO_N_Limitations="2"> MRL-WP7- - Page 29 of 50 08/12/2015

30 <sectionid="0001"/> <position="2458"/> </limit_end_location> <type_of_limit="lower"/> <power_limit="200"/> <energy_limit="0"/> </MAO_Limitation> <MAO_Limitation> <limit_start_location> <sectionid="0001"/> <position="3500"/> </limit_start_location> <limit_end_location> <sectionid="0001"/> <position="4000"/> </limit_end_location> <type_of_limit="upper"/> <power_limit="10000"/> <energy_limit="0"/> </MAO_Limitation> </FI_DOEM_LOS_MAO_Request> Table 6. FI_DOEM_LOS_MAO_Request message XML description MAO_Limitation Table 7 proposes MAO Limitation message exchange in XML Schema Definition Language. For a better understanding, an example is added. 1. MAO_Limitations: power and energy limitations to calculate the MAO estimation. Contains the following data: a Limit start location I. Section ID: track section where the limitation starts II. Position: train position (m) from the beginning of Section ID where the limitation starts b Limit end location c d e III. Section ID: track section where the limitation ends IV. Position: train position (m) from the beginning of Section ID where the limitation ends Type of limitation: indicates if it is an upper limitation (UPPER) or a lower limitation (LOWER). Power limit: power limitation in kw along the section defined by the start and the end locations. Value 0 or 0xFFFF means no limitation Energy limit: energy consumption in limitation in tenths of KWH between the start and the end locations. Value 0 or 0xFFFF means no limitation. <xs:element name="mao_limitations"> <xs:complextype> <xs:element name="limit_start_location"> MRL-WP7- - Page 30 of 50 08/12/2015

31 <xs:complextype> <xs:attribute name="sectionid" type="xs:landmarkid" use="required"/> <xs:attribute name="position" type="xs:trainpos" use="required"/> </xs:complextype> </xs:element> <xs:element name="limit_end_location"> <xs:complextype> <xs:attribute name="sectionid" type="xs:landmarkid" use="required"/> <xs:attribute name="position" type="xs:trainpos" use="required"/> </xs:complextype> </xs:element> <xs:attribute name= "type_of_limit" use="required"> <xs:simpletype> <xs:restriction base="xs_string"> <xs:enumeration value="upper"/> <xs:enumeration value="lower"/> </xs:restriction> </xs:simpletype> </xs:attribute> <xs:attribute name= "power_limit" type="xs:unsignedshort" use="required"/> <xs:attribute name= "energy_limit" type="xs: unsignedshort" use="required"/> </xs:complextype> </xs:element> Table 7. MAO_Limitation message XML description FI_DOEM_LOS_MAO_Reply Table 8 proposes MAO Replay message exchange in XML Schema Definition Language. For a better understanding, an example is added. XMLelement_ FI_DOEM_LOS_MAO_Reply DOEM LOS Attribute Type Description serviceid TrainRouteID Train service identification engineid EngineID Train engine identification timestamp Time Actual time UTC MAO_Id MAOID Identification of the MAO process (shall be equal to the ID of the request) DOEM_status unsignedshort DOEM acknowledges the MAO request returning one of the following values: 0x0000 = Unknown error 0x0001 = Forecast calculated successfully MRL-WP7- - Page 31 of 50 08/12/2015

32 MAO_N_P_Prof MAO_P_Profile unsignedshort MAO_P_Profiles 0x0002 = Calculation error 0x0004 = Limits ignored/overridden by driver/driving system 0x0008 = DOEM not operational 0x000F = Service not available 0x001F = Timeout 0x002F = Busy (other calculation undergoing) Number of points of the power profile (MAO_Duration x 60) / MAO_Timeslice MAO_N_P_Pref will be equal to zero if (DOEM_STATUS AND 0x0001) is equal to 0x0000 MAO estimation for LOS. As many MAO_P_Prof as MAO_N_P_Prof states. XSD <xs:element name="fi_doem_los_mao_reply"> <xs:complextype> <xs:sequence> <xs:element ref="mao_p_profiles" minoccurs="1" maxoccurs="unbounded"/> </xs:sequence> <xs:attribute name="serviceid" type="xs:trainrouteid" use="required"/> <xs:attribute name="engineid" type="xs:engineid" use="required"/> <xs:attribute name="timestamp" type="xs:time" use="required"/> <xs:attribute name="mao_id" type="xs:maoid" use="required"/> <xs:attribute name="doem_status" use="required > <xs:simpletype> <xs:restriction base="xs:unsignedshort"> <xs:enumeration value="0x0000"/> <xs:enumeration value="0x0001"/> <xs:enumeration value="0x0002"/> <xs:enumeration value="0x0004"/> <xs:enumeration value="0x0008"/> <xs:enumeration value="0x000f"/> <xs:enumeration value="0x001f"/> <xs:enumeration value="0x002f"/> </xs:restriction> </xs:simpletype> </xs:attribute> <xs:attribute name="mao_n_p_prof" type="xs:unsignedbyte" use="required"/> </xs:complextype> </xs:element> Example <FI_DOEM_LOS_MAO_Reply serviceid= 128 engineid= 2478 timestamp= T15:32: MAO_Id= 214 DOEM_Status= 0x0001 MRL-WP7- - Page 32 of 50 08/12/2015

33 MAO_N_P_Prof= 6 > <MAO_P_Profile> <sectionid= 0001 /> <position= 0 /> <avpower= 125 /> </MAO_P_Profile> <MAO_P_Profile> <sectionid= 0001 /> <position= 500 /> <avpower= 254 /> </MAO_P_Profile> <MAO_P_Profile> <sectionid= 0001 /> <position= 1200 /> <avpower= 780 /> </MAO_P_Profile> <MAO_P_Profile> <sectionid= 0001 /> <position= 1800 /> <avpower= 80 /> </MAO_P_Profile> <MAO_P_Profile> <sectionid= 0001 /> <position= 2500 /> <avpower= 630 /> </MAO_P_Profile> <MAO_P_Profile> <sectionid= 0001 /> <position= 4125 /> <avpower= -54 /> </MAO_P_Profile> </FI_DOEM_LOS_MAO_Reply> Table 8. FI_DOEM_LOS_MAO_Reply message XML description MAO_P_Prof Table 9 proposes MAO Power Profile message exchange in XML Schema Definition Language. For a better understanding, an example is added. Attributes Type Description SectionID UINT32 Track section ID for the power profile point Position UINT32 Train position (m) from the beginning of SectionID corresponding to starting position where the AvPower applies. AvPower INT16 Average power in kw between this power profile point and next point, located MAO_Timeslice time ahead. Table 9. MAO_P_Prof message XML description MRL-WP7- - Page 33 of 50 08/12/2015

34 Report function DOEM should report the LOS its status with the frequency requested during the linking process. The provided information should include the consumed energy. The LOS should answer this message with an ACK message. sd DOEM-LOS MAO DOEM LOS Report () Ackn () FI_DOEM_LOS_Report() Figure 13: Report sequence diagram Table 10 proposes Report message exchange in XML Schema Definition Language. For a better understanding, an example is added. XMLelement_ FI_DOEM_LOS_MAO_Report DOEM LOS Attribute Type Description serviceid TrainRouteID Train service identification engineid EngineID Train engine identification timestamp Time Actual time UTC sectionid LandmarkID Current track section Position TrainPos Train position (m) from the beginning of SectionID MRL-WP7- - Page 34 of 50 08/12/2015

35 DOEMstatus unsignedshort 0 = Unknown error 1 = Operational 2 = Standalone mode 4 = DOEM not operational energyconsumption unsignedshort Energy consumed in tenths of KWH since the startup of the DOEM. Two consecutive reports messages are needed to assess the relative consumption of a certain period of time. XSD <xs:element name= FI_DOEM_LOS_MAO_Report > <xs:complextype> <xs:attribute name= serviceid type= xs:trainrouteid use= required /> <xs:attribute name= engineid type= xs:engineid use= required /> <xs:attribute name= timestamp type= xs:time use= required /> <xs:attribute name= sectionid type= xs:landmarkid use= required /> <xs:attribute name= position type= xs:trainpos use= required /> <xs:attribute name= DOEM_Status use= required > <xs:simpletype> <xs:restriction base= xs:unsignedshort > <xs:enumeration value= 0 /> <xs:enumeration value= 1 /> <xs:enumeration value= 2 /> <xs:enumeration value= 4 /> </xs:restriction> </xs:simpletype> </xs:attribute> <xs:attribute name= energyconsumption type= xs:unsignedshort use= required /> </xs:complextype> </xs:element> Example <FI_DOEM_LOS_MAO_Report serviceid= 128 engineid= 2478 timestamp= T15:16: sectionid= 0001 position= DOEM_Status = 1 energyconsumption = 150 /> Table 10. FI_DOEM_LOS_Report() message XML description MRL-WP7- - Page 35 of 50 08/12/2015