1 Introduction

Rising energy prices and fluctuating power generation by decentralized sources into grids that were not designed for this purpose are controversially discussed topics nowadays. The introduction of E-Mobility is another topic which is regularly named in this context. With the introduction of E-Mobility to maritime container terminals new possibilities for the terminal operator arise to optimize the energy demand. Not only does the relevance of energy demand rise in the operational strategies but also for the first time flexibility in regard to the time of the energy demand can be, at least in parts, achieved. This flexibility results from the fact that there is a possibility to control, within a certain range, the point in time when the battery of the vehicle is recharged. The basis for the use of this flexibility is the knowledge about the expected power demand of the container terminal. In order to forecast this demand while having highly dynamic, non-periodical handling and transport processes and to furthermore determine and use flexibility most effectively, e.g. by offering grid services, the support of information- and communication technology is needed. Within the project BESIC “Battery-electric heavy duty vehicles in intelligent terminal operations” a software-architecture was developed to assist the determination and the usage of flexibility in the power demand at a container terminal. This architecture is related to the environment “flexible consumer” of the electricity market reference architecture (ERA). In the following chapters this architecture will be introduced. In order to do so, the term demand side integration is derived from the established terms load management and demand response which are also shortly defined. After that, the ERA, and especially the environment “flexible consumer” is described, before the developed architecture model is presented in detail. This includes a description of the maritime container terminal altenwerder (CTA) as it is the location for the case study, the introduction of the different components of the architecture and their functions as well as a chapter on the similarities and the differences between the ERA and the developed architecture. The paper closes with a look on first results, an outlook on future developments, and the future usage of the application in daily operations.

2 Load management and demand side integration

Even before the liberalization of the electricity market, the optimization of power demand was a matter of importance in industrial enterprises with high energy consumption. Peak load avoidance and the shifting of demands into time ranges with lower prices have been supported by grid operators with the introduction of peak load based tariffs and different day and night rates.

Energy management systems are monitoring the business operations and, if possible, control the energy demand. If the control reacts to external signals the process is called “demand response” [1]. These signals can be dynamic price signals, e.g. derived from the electricity exchange, but also further event signals to reduce or to raise the power consumption. This can be the case if frequency variations occur in the transport grid or if a huge amount of renewable energy is available within the grid. Demand side management (DSM) includes the execution of general actions to increase energy efficiency at the demand side or power control procedures like peak clipping or load shifting without reacting to external signals [2]. The German electricity organizations VDE and BDEW sum up the terms demand response and DSM in the term demand side integration [3, 4].

High potentials for the integration of the customer side to energy related activities in the context of DSM are named in several surveys. For Germany the potential for the use of flexible loads is estimated to be about 2,700 MW [4]. Different studies name first of all the energy-intensive industries (aluminum, chemistry, steel, paper, cement) as target group for respective actions [5–8]. Further studies investigate the possibilities and the potentials for household customers [9, 10]. The logistic industry is named or investigated in neither of these studies.

3 The electricity market reference architecture

The “electricity market reference architecture” (ERA) is a software architecture that is used as a basis for the development of information and communication technology of future energy systems [11]. The architecture has its origin in the German research project eTelligence. In this project a regional integrated electricity market was designed and implemented. The ERA itself was not used for this purpose but is rather the result which is used to pass the experience of the project on to other smart grid projects [12]. The ERA development was based on existing conceptual approaches like IntelliGrid [13]. The architecture is a pattern for the realization of decentralized electricity grids and their components and describes the involved market roles and their functions in an abstract way, independently from any technology used for the actual implementation. The views of the architecture relate to the four layers of the open group architecture framework (TOGAF): business process-, data-, information system-, and technology-view. In order to represent the architecture on the level of the different views component diagrams of the unified modelling language (UML) are used. The components are modeled as an enclosed unit that encapsulates system functionality externally. The structure of the components roughly relates to the market roles of an electricity market. Every market role is modeled as its own component, called environment, which itself can contain sub-components. The dependencies between the different components are described independent of the technology using so called ports which are supposed to be realized by respective interfaces.

Following a generic market structure the following environments are defined: “grid operator”, “energy service provider”, “trader”, and “market”. Additionally the end points of the grid exist, represented by the environments “producer”, “consumer”, and “storage”. The first two of these three are described in a static way as well as with dynamic functions like load shifting potentials. They are then named “flexible producer” and “flexible consumer” respectively. The component “measurement service provider” collects, administrates, and provides metering data to other components.

3.1 The flexible consumer within the ERA-reference architecture

The environment “consumer” represents a consumer of electricity within the ERA-reference architecture. A mostly static load curve for this customer is assumed. The demand of the consumer can either be forecasted or the forecast can be provided by external services as well as by the component itself. On the basis of this data the business activities of the consumer have the goal to cover the electricity demand as economically as possible by trading at the electricity market or by assigning an energy service provider to do so. In contrast, the “flexible consumer” possesses controllable consumption units which enable load shifting. Both small shifting potential with a high amount of static demand as well as the potential for shifting high loads are possible. As examples for” flexible consumers” cold storage houses as well as electrical heaters used in households are named [11].

The environment “flexible consumer” is built up of the following components (Fig. 1):

  • Metering infrastructure

  • Data management

  • Unit-controller

  • Market agent

  • Control agent

  • Control center/visualization

Fig. 1
figure 1

Structure of the ERA environment “flexible consumer” [11]

Full size image

The component “metering infrastructure” provides metering data. This includes the overall consumption (sub-component “meter”) as well as the consumption of single individual electrical units (sub-component “sub-meter”). The metered data is provided to internal as well as external components for purposes of administration, billing, and visualization and is stored in the “data management” component. The purpose of the data management is the central data processing and storing component for all relevant data of the environment. Using a Publish-/Subscribe service, messages with the relevant data are sent to registered components that are subscribed to the respective event.

The “unit controller” is responsible for the control of connected energy units. This can be accomplished using a standard-based protocol or by the use of a proprietary protocol and the help of a respective adapter. All connected energy units sign up to the “unit register”. This component is part of the “control agent”, which consists of the components “energy management”, as the part responsible for creating power demand forecasts and schedules regarding all units, the “control service” for the controlling of external access to the units and a “controller” that is responsible to actually process the schedules generated from the energy management component besides the unit register.

A special task is performed by the “market agent”. This component realizes the communication and works as an interface to external market participants. In regard to the availability of possible offerings and knowing the flexibility in the power demand of the connected electrical units, offers are obtained and bids are placed. The component “market service”, as part of the market agent, is responsible for the communication with external parties, the authentication and the intermediation of external request to internal components. Potential offerings, e.g. the amount of flexibility for a point of time during the next day, are prepared and administrated by the trading management component. In respect to the power demand requirements of the registered electrical units, different possible schedules are evaluated in regard to different target functions and provided to the market service. In the other direction the “trading management” is also responsible to administer accepted offerings submitted by the market agent and the execution of the corresponding schedules. The component “clearing” is designated to realize all functions in regards to energy billing procedures of the consumer.

The market agent is in contact with the control agent at all times. He is responsible for the utilization of the demand forecasts and sends feedback if the interaction with the market was successful. The “control center” provides the user interface (component “visualization”) of the environment. It is divided into the maintenance component for maintenance purposes, a “consulting” component for decision support functionalities, and a “feedback” component for the display of status, market, and metering data.

4 IT-Architecture for intelligent energy management at CTA

4.1 AGVs at the maritime container terminal altenwerder

The CTA started operations in the year 2002 and represents a highly automated maritime container terminal located in the harbor of Hamburg in Germany. Every year several million containers are handled by the terminal. The buildup of the terminal generally follows the well-established requirements of container terminal design (Fig. 2), but with a special focus on the automation of logistic processes.

Fig. 2
figure 2

Layout of the container terminal altenwerder [14]

Full size image

To reach the goal of high automation self-driving container trucks, so called automated guided vehicles (AGVs), are used for transport purposes within the terminal. The AGVs are responsible for the container movement between the quay cranes, which handle the loading and unloading processes from the containerships, and the yard where the containers are stored until further processing.

Originally, all AGVs have been equipped with diesel-electric drive chains. However, recently 10 vehicles have been converted to a battery-electric drive chain, to allow for a more eco-friendly and possibly ecological transport. It was decided to use a concept with exchange-batteries as energy storages for the vehicles. In current operations for every battery-AGV two battery systems are assigned: one is usually used in the vehicle while the second battery system is loaded and then stored in a battery-exchange station. If the load level of the battery system located within an AGV drops below a certain minimum, the AGV automatically drives to the exchange station where the battery systems are switched and the discharged battery system is recharged. Due to the fact that the recharge-time of the battery is less than the operation time of a battery system in the vehicle, flexibility arises in regard to the point of time when the battery is actually recharged and electric power is demanded. With this case, the CTA becomes a flexible consumer as described in the ERA.

4.2 The architecture of the flexible consumer at CTA

Support of information- and communication technology is needed in order to use the potential flexibility in the power demand created by using the battery exchange concept. During the project BESIC a software architecture was developed that supports the forecast of flexibility in the power demand as well as the utilization of this flexibility. The core of the architecture is made up of the two components “logistics simulation” and “energy demand optimization”.

The component “logistics simulation” (Fig. 3) is used to forecast the logistic processes at the terminal and derives from this forecast the overall power demand of the terminal as well as the points of time at which battery exchanges occur and their following time frame for the stay within the exchange station. A complete simulation of all logistic processes is needed because the activities in the terminal are highly dynamic and first of all relate to the daily changing quantity of ships arriving and the corresponding number of containers to be handled. Established methods for power demand forecasts like extrapolation based on historical figures are not applicable under these circumstances. Additionally, the points of time when a battery exchange occurs are highly dependent to the distance driven by the AGVs.

Fig. 3
figure 3

The logistics simulation component

Full size image

The logistic simulation abstracts the terminal into the three sub-components “ship berthing area”, “transport area”, and “container yard”. The “ship berthing area” (short: “shipping area”), simulates the arrival, the berthing and the departure of the single ships based on the so called sailing list. In this list all arrival and departure times as well as the number of containers to be handled per ship are listed in a plan for the next days. In order to load and unload the containers from or to the ship, quay cranes are assigned to each vessel. The number of cranes depends on the number of containers to be loaded and unloaded as well as the berthing time. In the transport area the containers are transported by AGVs using a specified routing layout between the quay cranes and the yards where the containers are carried over by rail mounted gantry cranes. If the battery level of an AGV’s battery system drops below a certain threshold, the AGV is automatically directed to the battery exchange station where the battery system is switched. The battery exchange station itself is also modeled as part of the transport area.

In the container yard area the containers are received from the AGVs and stored. This includes relocation processes as well as special storage areas for refrigerated containers. A special feature of the simulation is that for all logistic processes the power consumption is permanently monitored and registered. Each quay crane, for example, has its own specific power demand profile for every part of its loading or unloading process. This includes the lifting, the movement, and the dropping of a container as well as the power consumption in idle state. Additionally, further predominantly static consumers like lighting, consumption of administration buildings and also the hinterland connection are incorporated. This way the overall power consumption is determined and a forecast load curve can be calculated.

The “energy demand optimization” component receives the forecasted load curve and the battery exchange times to optimize the power demand using the flexibility of the battery charging. Different optimization objectives can be pursued. These objectives can be, for example, the optimization regarding variable pricing, the optimization regarding the offering of control reserve power, avoidance of new load peaks, or the charging of the batteries in times of high availability of renewable energy. It is the task of the “energy demand optimization” module to utilize the available flexibility as economic as possible. The battery charging schedule and time point of battery exchanges can be changed, but only under the assumption that the logistic processes are not affected. To secure this requirement the optimized battery charging schedule is always verified using again the simulation. For this purpose the simulation is run once again with the optimized schedule as input and the ship departure times are compared to the originally stated ones from the sailing list (Fig. 4).

Fig. 4
figure 4

Energy demand optimization component

Full size image

Besides the two core components of the application further components are needed that support the optimization based on the simulation. These components are bundled in the “energy controler” module and are responsible, as interface components, for the communication with energy market participants and external components like the connected and registered electrical units, and control the execution of the optimized plan. The components “load curve revision” and “operating plan revision” are responsible for the last task. During the day of the plan execution these two components control the affected electrical units and the power demand. The local energy management system constantly monitors the power demand. If the currently metered power demand diverges remarkably from the planned one or if the point of times when the AGVs arrive at the battery exchange station for a battery exchange are not in sync with the forecasted ones, it can be assumed that an unforseen event has happened. Such an event can occur because of a change in processes due to weather conditions or the delayed arrival of a ship. If such an event is noticed the optimized plan is discarded. The system then automatically returns to the default behaviour for battery exchanges and battery charging. In this default behaviour the battery charging starts once the battery has entered the exchange station from the AGV. With this procedure negative influences on the logistic processes by the energy demand strategies can be avoided.

The “unit controller” is responsible for the actual execution of the planning. It passes the requirements regarding battery exchange times on to the AGV management system and sends the planned battery charging schedules to the battery administration system. The component “data management” has the tasks to retrieve the newest sailing list and the number of containers per ship from the terminal management systems, to save all relevant data, and to provide data to other components if necessary. The component “economic utilization” represents the interface to external market roles of the energy market. The component receives price information or incentive signals. Control reserve power orders are processed and passed on to the concerned components like the unit controller. The placement of bids and offers is also conducted by this component.

The communication between the different components of the overall architecture (Fig. 5) is designed to be connection-oriented and depends on the communication demand. To develop a lean structure and guarantee a dependable message transmission, a Publish-/Subscribe-solution was abandoned. The software can be called from external sources using a defined set of of instructions and takes charge of the communication with the connected electrical units like the AGV management system or the battery administration system accordingly.

Fig. 5
figure 5

Overall system architecture

Full size image

4.3 The flexible consumer of the CTA in the context of the ERA

The “Electric Market Reference Architecture” provided a good starting point when beginning to think about how to build up the architecture. It seems complete in regard to needed components and the description of the components tasks and their linkage, so the first architectural designs of the software to implement can easily be checked against the ERA in regards of completeness of functionality.

In the implemented architecture for the container terminal all components of the “flexible consumer” as described in the ERA are found, although some differences can be named. During the design and the implementation there was a strong focus on the development of the “control agent”. The reference functions of the agent can be found distributed within the BESIC architecture. Especially the two core components “logistics simulation” and “energy demand optimization” are considered as the component “energy management system” in the reference architecture while they are separated into two components with further sub-components in the implementation. The separation has been selected on a logical level since they also represent two different functionalities within the architecture. This is due to the highly dynamic processes and the complexity of the power demand forecast. In other scenarios with recurring processes this differentiation might not be needed or the energy demand forecast might be executed by an external component as suggested by the ERA as an option. Also attached to the implemented architecture an external local “energy data management system” can be found. This system is responsible for the metering of the electrical units within the terminal and can therefore be allocated to the component “metering infrastructure” and might not be mixed up with “energy management system” of the reference architecture. The “market agent” of the reference architecture is represented by the “economic utilization” component, but the “energy demand optimization” module takes over the functions for the economic evaluation so that the component is reduced to the functions of mediation between the BESIC architecture and external market partners.

As stated in the previous chapter, there was a focus on the guaranteed transmission of messages between the different components of the architecture. Due to this fact a Publish-/Subscribe-Solution for message exchange, as proposed by the reference architecture especially for the “data management”, was discarded (no further functional requirements regarding messaging are named by the reference architecture). The risk of lost messages was considered too high.

5 First results and future usage

With the presented component-based architecture for demand side integration at a maritime container terminal it is possible to use the determined flexibility in the energy demand for different optimization objectives. The flexibility is established by using battery-electric AGVs with exchange batteries. A combination of different optimization goals can also be regarded. A combination can be, for example, the optimization regarding variable pricing while at the same time trying to offer reserve control power. First results show that with the energy demand forecast and the optimization of the flexible loads an amount of up ten percent of the energy costs for battery charging can be saved. For the this results the day-ahead EPEX-Spot prices have been used for the variable pricing and day-ahead auction results for minute reserve power at regelleistung.net, the Internet platform for control reserve tendering from the German transmission system operators. Especially the offering of minute reserve power seems to be promising in regard to save energy costs by gaining money from offering grid services.

In order to use the software in later daily operations it has to be integrated into the present IT-landscape of the terminal. One particular barrier here is the operational impact on the AGV management system since this system directly controls a crucial part of the logistic processes. In order not to negatively interfere with these processes the revision components have been introduced. With these components it is assured that a fallback to non-interfering behavior is conducted as soon as a major deviation from the plan is noticed. A complete re-planning after the detection of deviations was disregarded in a first step, but might be added in the future.

The integration into the current IT-landscape takes place after the validation, particularly of the simulation component. During the validation power demand of single electrical units of the terminal is closely monitored, forecasted ship arrival times are compared to the effective arrival times and the driving data from the AGVs in the terminal is compared to the transport data of the AGVs in the simulation. The simulation component additionally allows trying out different infrastructure settings for the terminal. For example, the number of battery-AGVs can be varied virtually as well as the number of exchange batteries available. The effects on the logistic processes and the power demand can be analyzed easily this way. After a successful validation a test in the field will be conducted to test the results of the optimized planning under real circumstances.

During the later daily operations the determination of the flexibility, the optimization of the use of this flexibility and the respecting validation of the planning will be conducted the day before the real processes are handled. Only on the day prior to the actual execution, changes in the sailing list are minor enough to allow for an exact forecast and interaction on the energy market is still possible. For example, the bids for control reserve power have to be placed the previous day. However, the control and surveillance of the optimized processes will be active during the execution of the real processes.