Functional specification Smart Grid system - e-harbours

REloadIT
Functional & Technical Design
Designed by the municipality of Zaanstad
Version 0.8
Date: 30-11-2011
State: concept
REload T

Contents
2
Content 2
Figures 2
Functional specification Smart Grid system 3
Introduction 3
Basic features Smart Grid system 4
Design strategy business agent 4
Visualisation 5
Data processing and reporting 5
System architecture 7
Software architecture SG-system 8
Scope of work en deliverables 9
Completions 9
Materials 9
Documentation 9
Activities 9
Maintenance and guarantees 9
Quality Assurance 9
References 10
Attachment: Elaboration functional specifications 11
Figures
Figure 1: Proces flow schema van het SG systeem ............................................................................................. 3
Figure 2: Concept systeemarchitectuur REloadIT ............................................................................................... 7
Figure 3: Concept software architectuur c.q. proces data flow ReloadIT ........................................................... 8

Functional specification Smart Grid system
Introduction
A Smart Grid system (SG) consists of a cluster of multiple independent energy sources and energy users, who
share energy and information through an electricity and ICT network respectively. The purpose of a SG is, on
the basis of a specific business case, to use consumption of electricity and sustainable energy production in
an optimized way. Examples of business cases are: peak shaving, i.e. to improve the power profile of the
distribution network by moving the profiles of the various users and producers. This reduces the peak
consumption and the lowers the impact on the distribution network. This peak can also be avor something
comparableed in the contract fees. Another business case is to financially benefit by offering flexibility
(valleys and peaks in power consumption) to the system operator. In the framework of this project the main
goal is to use of the available sustainable energy for the benefit of the electric transport in an optimized way.
Figure 1 shows a schematic representation of the intended SG-system in the form of a process flow scheme.
3
Device Agent
PV systeem
(3)
Divice-Agent
Laadstation
(of per
laadpaal?)
Figure 1: Proces flow schema van het SG systeem
Device Agent
Wind turbine
Priority manager
Busines Agent
Meteo
service
The SG-system has a hierarchical structure and is composed of a Priority Manager, a Business Agent, and 1 or
more Agent-devices. In a more extended SG-system there can be multiple Priority Managers be included. In
the context of this project due to the small size of the cluster 1 Priority Manager is sufficient.
The Agent-devices sign up at the Priority Manager. For each device (the source of energy or an energy user:
charging station and solar installations) the Device Agent calculates the priority, this determines the choice
of the device to consume or produce energy again. The Agent-devices give this information to the Priority
Manager. The business agent interprets the business rules in combination with the weather forecast, and
sends it to the Priority Manager.
This Priority Manager in turn calculates the asset allocations per device, based on the information retrieved
from the device agents and the business agent. The allocations are then given back to the Agent-devices. The
entire system per time slot rotates cyclic: the business case of e.g. 15 minutes passed and information
exchanged. In this case should be to maximize the energy yield of 3 solar installations and future wind
turbine for electric transport. The business rules (or line strategy) are described in the next chapter.

Basic features Smart Grid system
Design strategy business agent
Managing the load of the SG will take place on the basis of the rules established by the Business Agent be
passed:
1. Maximum the use of the available solar energy (and later also the wind energy). I.e. charge vehicles with
to the maximum daytime loading state of charge with renewable energy. The surplus of electricity is
delivered back to the municipality of Zaanstad through the distribution network.
2. Take advantage of difference in tariff between the day and night if the renewable energy predicted for the
day is insufficient.
3. The state of charge of the 16 vehicles should be guaranteed using the user parameters such as: the
scheme with driving times, the desired minimum driving distance, and the time interval on which the
vehicles should be available. Alternative: the charging station if 1 large battery. Here IMTECH information is
still required.
4. If possible: Delivering energy back to the grid by the batteries if there is a surplus based on the planned
transport by the vehicles.
ICT infrastructure
For the benefit of communication and linking of peripheral devices to the SG-system serves an ICT network
needs to be available. In the chapter system specifications, the specifications of this ICT infrastructure are
further elaborated.
Data-acquisition and control
An important central part of the SG-system is the periodically viewing and controlling (if necessary
modifying) of all the parameters of the Agent-devices. We distinguish the following components:
1. The 3 PV installations, (type inverter? Interface Specification? Information required from Zaanstad).
2. The charging station, upgradeable to a maximum of 32 loading piles, (type? Interface? Here IMTECH
information is required).
3. The wind turbine (s).
4. Interfaces with external systems such as the meteo-server for the weather forecast.
Data storage system
The function of the data storage system is to secure all relevant data as a source to analyse the data of the
SG-system. This information can then serve again to learn and improve the REloadIT SG system.
Besides that it serves as a source of information for the reporting tools, and the (web) applications with
which the data can be shown to the public. The data is regular be saved, at least once per 15 minutes.
4

Visualisation
Results of the measurements are compressed and displayed on a graphic display via a Web application
(whether or not publicly available).
For example: a publicly available web-display with information about "sustainable transport Zaanstad" which
shows:
• The percentage or number of kilometres driven on renewable energy.
• Week production of the PV installations and wind turbines versus current meteorological data.
• State of charge of the batteries.
• Equipped with the logo of e-harbours, Zaanstad, Interreg, REloadIT.
• In addition, explanations about relationship between the weather, the sustainable energy generation, and
the electric transport.
• Information per automobile or user. What is possible with the current loading pole system?
Data processing and reporting
The source of the data processing and reporting is the data storage system in the form of the database (SQL
server or mySQL or something comparable). The database should be accessible via an open interface (such
as ODBC).
Reports can be carried out using standard tools such as MS Access and Excel. There is no need for the
development for special applications.
5

System specifications
Principles system design
1. The system should preferably be scalable, implying that by extension of an existing type energy supplier or
user this is possible without reviewing the entire platform. Let´s see what is and is not feasible. The system
should be scalable in the sense that the system is expandable: the interfaces between the equipment within
your own standard should preferably be uniform. The intention is that later, wind turbines and WKO (heat
cold storage) and maybe pumps can be included in the business case.
2. The equipment shall be preferably wireless exchange information.
3. The SG-system is preferably platform independent. Windows and Linux is allowed although for desktop
data processing a link with Windows is required.
4. All stored data should be accessible in a database, accessible via an open interface such as ODBC.
5. Determination of the hardware environmental specifications such as location, housing, temperature,
humidity, dust etc. TBD
6. Choice hardware for the MMI (man machine interfaces). Whether or not to use local displays.
7. Local power supply: a UPS with a capacity of approx. 30 minutes to disable the system checked himself.
8. Failure of the ICT infrastructure should the charging station and the solar installations continue to work
autonomously.
9. Dial-up facility for maintaining the system (VPN, in consultation with ICT service Zaanstad). nice to have
6

System architecture
The base platform is composed of the following components (see Figure 2: Concept REloadIT system
architecture):
7
Agent device
laadstation
Laadstation
Console laadstation
Agent device
PV systeem (3*)
Internet
VPN
Publieke web applicatie
Figure 2: Concept system architecture REloadIT
Agent device
Windturbine
Fire wall
RF router
Workstation gemeente Zaanstad,
Smart Grid server
GUI reserveringssysteem
LAN Zaanstad
Extern: Meteo server
1. A central Workstation (IPC or something comparable), which established the coordinating role of the
total system, and database, and the web application (s) serves.
2. The charging station of Imtech (type? Here IMTECH information is still required).
This station is equipped with an Ethernet or wireless interface through which information can be
exchanged with the Workstation through a specific protocol. Minimum requirements are: the
system should be without customization in the design or in the software are suitable for a maximum
of 32 loading points.
3. Control console for the car users (is this possible given limited intelligence cars? To fill in more detail:
location, features, ….)
4. 3 solar installations on 3 independent locations. The plants each have a inverter that convert solar
energy into electrical energy and inject on the 220 Volt distribution system. The inverter also
contains an interface (Brand type and type of interface naming), with which it can communicate to
the Smartgrid-platform real-time yield of the Panel read out. (Shows the inverter in a closed space
produced or outdoors?).
5. A display panel that is being drafted in the town hall for the view of the main results of the system
(further to be specified during implementation). Display with Web application (Central Workstation
on which the SG-can software runs).
6. Meteo interface: link to a real or simulated interface with a weather forecasting system used for
predicting the yield of wind and solar energy in the SG-system.
7. A link with the car reservation system. Further define (e.g. a link with Outlook that the 16 cars can be
scheduled).
8. A backup system: of the measuring data and parameters should be backed up once a week.

Software architecture SG-system
Figure 3: Concept software architectuur c.q. proces data flow ReloadIT
Explanation and design considerations on behave of the scope will follow.
8

Scope of work en deliverables
Completions
Materials
All components such as described in the previous paragraph, and to the extent not explicitly indicated, all
necessary components to complete working system to deliver.
Operational costs and consumables such as communications and internet costs, travel and subsistence costs,
etc…
Not within the scope of these specifications : the loading pole infrastructure and ICT infrastructure at least
the fixed network.
Documentation
Documentation package consisting of the following components:
1. Quality plan software or system development (extract).
2. Test plan or factory and site acceptance test (FAT and SAT) for the SG-system.
3. Electrical drawings of the hardware, especially the interfaces with the infrastructure and peripherals
(as built).
4. Basic design software (as built).
Activities
1. Design and development of the SG system.
2. Operation of the system on behave of a SAT plan designed by the contractor
3. Operational maintenance of the entire system until 31-12-2013.
4. The provision of data to the end users through authorization system of the Zaanstad. and data
format accessible through the Central drafted Workstation and database.
5. Manual control functions charging pole
6. Technical documentation where relevant for the end users and maintenance of the system.
Maintenance and guarantees
1. Keep the entire system operational during the period of the project contract of delivery until 31-12-
2013.
2. Contacting a disturbance within 3 working days through a contact person (account manager project
or building administrator), and solving a disturbance withing 7 working days. TBD
3. Failure of seller to replace the ICT equipment during the turnaround time of the project contract.
Property rights
The supplied equipment is owned by the municipality of Zaanstad.
The software supplied, at least the binary executables or objects are owned by the municipality of Zaanstad.
The IP of the VPP-software and the source code of the software are the property of the contractor.
Quality Assurance
The quality aspects include the following aspects:
1. safety equipment must all comply with the CE marking requirements for Electrotechnical equipment.
2. contractor has the right to perform design reviews before proceeding to the actual implementation.
3. Site acceptance testing of the system and part systems are carried out by the contractor and client a
jointly drawn up by the contractor and obv by the Zaanstad approved test plan.
4. the contractor must prove that they work according to a quality system including development
methodology, test procedures, and a part version control system.
9

Planning
See also the project plan (Ref 1). Within that framework, we distinguish the following phases and milestones:
1. Define system requirements and user requirements to be approved .
2. Review basic design system design of awardee by Zaanstad .
3. Understand the prior design detail
4. implementation
5 hardware and software deployment. Decrease test system, and the functional and system specifications
part system obv.
6. installation on location
7. Decrease test on location
8. Acceptance total system
9. Commissioning total system
10. Maintenance of the system
11. Evaluation and adjustments (outside this scope and post-calculation obv).
To mile stone 9 is the turnaround time 4 months, counting from ordering to delivery.
References
Ref 1 Project plan REloadIT
Ref 2 Specification IMTECH interface
Ref 3 Specification PV-inverter ???
10

Attachment: Elaboration functional specifications
11