This deliverable is the initial version of the GreenCharge reference architecture. It supports the understanding of the GreenCharge concept and serves as a blueprint for planning and construction of systems and system components that together realise the concept. The modified and/or or added responsibilities and collaboration patterns necessary to support the concept are defined.
The GreenCharge concept is that electric vehicles, charge management and local energy management work together to facilitate a transport system running on green energy. Users of electric vehicles get charging support, and peaks in the power grid and grid investments are avoided through a balance of power. When many vehicles are plugged into the grid around the same time (e.g. on returning home from work), the energy management balances demand with available supplies. Supplies from local renewable energy sources and batteries in connected vehicles not in use may also be utilised. The concept also includes viable business and price models rewarding charging behaviour contributing to peak reductions.
The architecture description provided in this deliverable uses terms and concepts from the standard ISO/IEC/IEEE 42010 Systems and software engineering — Architecture description (ISO/IEC/IEEE 2011), and the deliverable is also structured according to recommendations from this standard.
The architecture description identifies the stakeholder types playing a role in the realisation of the GreenCharge concept and their motivations and concerns. The main stakeholder types are:
• EV User. An electric vehicle (EV) User is a person or a legal entity using one or more electric vehicles. The EV Users wants predictable access and high availability of charge points and low mobility costs, as well as assistance for smart charging.
• eMobility Provider (EMP). The EMP provides electric vehicle charge services to EV Users. The EMP wants the provide competitive and attractive charge services, reduction of charging energy costs, optimal utilisation of charge points and low investments costs in grid infrastructures.
• Charge Point Operator (CPO). The CPO is responsible for the provisioning and operation of the charging infrastructure and for managing electricity to provide requested energy transfer services. The CPO wants effective and attractive charge management that can facilitate charging adapted to energy availability and end user services that rewards flexible charging and provides predictable charge point access.
• Roaming Operator. The Roaming Operator facilitates authorisation, billing and settling procedure for electric vehicle charge service roaming, between two roaming endpoints (operated by EMPs and/or CPOs). The Roaming Operator aims for competitive roaming services.
• Local Energy Manager (LEM). The LEM manager aims for optimal use of locally produces green energy and manages the use and storage of energy in a local energy community or a part of such a community (building, neighbourhood, charging infrastructure, etc.). Energy demanding activities, charging included, are planned and controlled dependent on current and foreseen energy demands and energy availability.
Different architecture views address different perspectives of the system of interest which is the integration of systems/system components that facilitate a realisation of the GreenCharge concept:
• The context view provides a use case model. It describes the functionality needed by a decomposition into detailed use cases. A use case to service mapping model links the use cases to logical system components (services). An environment model defines the environment in which the solution will operate.
• The requirement view defines generic and principal requirements for the realisation of the GreenCharge concept and related information exchange. The overall concerns of the stakeholders are used as a starting point, and the detailed requirements are derived from use cases and other sources.
• The component view addresses how the logical system components collaborate and interact. An information model defines the information exchanged, a system component and interface model identifies interfaces and messages used for communication, and a system collaboration model defines the interactions.
• The distribution and the realisation views are not defined since the reference architecture description does not define the physical realisation of the solution into components.
To ensure the necessary openness, the reference architecture has generic specifications and is modelled as a set of services collaborating through message exchange, The implementation onto underpinning systems is left to each deployment. All the architecture views listed above have guidelines describing how this can be done.