d1.3 flexmeter report on platform requirments data...

FLEXMETER 646568 D1.3 Report on specification of the distribution network H2020-LCE-2014-3

Public

FLEXMETER

H2020-LCE-2014-3

Flexible smart metering for multiple energy vectors with active prosumers

Project Duration 2015-01-01 - 2017-12-31 Type CP

WP no. Deliverable no. Lead participant

WP1 D1.3 SIVECO

Platform requirements, data formats and protocols

Prepared by SIVECO

Issued by FLEXMETER Project Office

Document Number/Rev. FLEXMETER/D1.3/V3.0

Classification PU

Submission Date 2015-12-01

Due Date 2015-11-30 This project has received funding from the European Union’s Horizon 2020 research and innovation

programme under grant agreement no. 646568

©Copyright 2015 POLITECNICO DI TORINO, IREN ENERGIA SPA,

STMICROELECTRONICS SRL, TELECOM ITALIA, RHEINISCH-WESTFAELISCHE TECHNISCHE HOCHSCHULE AACHEN, INSTITUT POLYTECHNIQUE DE GRENOBLE, UNIVERSITATEA POLITEHNICA DIN BUCURESTI, SIVECO ROMANIA SA, ALMA MATER STUDIORUM – UNIVERSITA’ DI BOLOGNA, E-ON SVERIGE AB.

This document and the information contained herein may not be copied, used or disclosed in whole or in part outside of the consortium except with prior written permission of the partners listed above.

FLEXMETER 646568 D1.3 Platform requirements, data formats and protocols H2020-LCE-2014-3

/ 61

Document

Title Platform requirements, data formats and protocols

Type Deliverable

Ref D1.3

Target version V3.0

Current issue V3.0

Status Final

File D1.3_flexmeter.pdf

Author(s)

Reviewer(s) All consortium

Approver(s) Andrea Acquaviva

Approval date 2015-11-27

Release date 2015-11-30

Distribution of the release

Dissemination level PU

Distribution list All consortium History of Changes Date Version Comments 2015-08-26 1.0 First draft

2015-09-18 2.0 Update of deliverable with architecture elements and data model information

2015-11-27 3.0 Final integrated version of the deliverable, with approval of the involved partners

TABLE OF CONTENTS


/ 61

1. PURPOSE.......................................................................................................................................5

1.1 SCOPE.................................................................................................................................................51.2 DEFINITIONS,ABBREVIATIONSANDACRONYMS...........................................................................................5

2. ARCHITECTURALREPRESENTATION...............................................................................................6

2.1 PRESENTATIONLAYER.............................................................................................................................62.2 BUSINESSLOGICLAYER............................................................................................................................8

2.2.1 Micro-serviceslayer.................................................................................................................82.2.2 ServiceLayer..........................................................................................................................102.2.3 Applicationgeneralstructure................................................................................................112.2.4 Javamessagingservice..........................................................................................................162.2.5 ApplicationMessageBroker..................................................................................................162.2.6 Energystorage.......................................................................................................................19

2.3 PRESENTATIONLAYERMODULESDESCRIPTION...........................................................................................212.3.1 Usermanagement.................................................................................................................212.3.2 Assets.....................................................................................................................................22

2.4 BUSINESSLAYERMICRO-SERVICESDESCRIPTION.........................................................................................262.4.1 Connectionbetweenmoduleandservice..............................................................................26

2.5 DATABASELAYER.................................................................................................................................322.5.1 Localdatabase.......................................................................................................................332.5.2 Users......................................................................................................................................332.5.3 Reports...................................................................................................................................332.5.4 Assets.....................................................................................................................................33

3. BUSINESSINTERACTIONS............................................................................................................34

3.1.1 IRENdemoproject.................................................................................................................343.1.2 E.ONdemoproject.................................................................................................................353.1.3 Limitations&Exclusions........................................................................................................37

4. BUSINESSPERSPECTIVE...............................................................................................................38

4.1.1 BusinessObjectives................................................................................................................384.1.2 Businesssuccessmetrics........................................................................................................39

5. BUSINESSCAPABILITIESDECOMPOSITION...................................................................................40

5.1.1 Functionalcapabilitiesdecomposition...................................................................................405.1.2 Non-functionalcapabilitiesdecomposition............................................................................40

6. USERPERSPECTIVE......................................................................................................................42

6.1.1 Userrolesandprofiles...........................................................................................................42

7. FUNCTIONALANDNONFUNCTIONALREQUIREMENTS................................................................45

7.1.1 Layoutpresentation...............................................................................................................457.1.2 SignInpagelayout................................................................................................................457.1.3 DashboardforProsumerAccount.........................................................................................467.1.4 ElectricmeterforProsumerAccount.....................................................................................477.1.5 AlertsforProsumerAccounts.................................................................................................487.1.6 PersonalInformationforProsumerAccounts........................................................................497.1.7 DashboardforDSOAccount..................................................................................................507.1.8 OverviewforDSOAccount.....................................................................................................517.1.9 BuildingsProfile.....................................................................................................................527.1.10 Prosumersprofile...................................................................................................................537.1.11 Alertsdisplayforprosumers..................................................................................................547.1.12 ProfileforDSO........................................................................................................................557.1.13 DashboardforretailerAccount..............................................................................................56

7.2 FUNCTIONALREQUIREMENTS.................................................................................................................57


/ 61

7.2.1 RegisteringintheApplication................................................................................................577.2.2 UserSign-In............................................................................................................................577.2.3 Homepage(Dashboard).........................................................................................................577.2.4 Header...................................................................................................................................587.2.5 Navigation.............................................................................................................................587.2.6 AccesstoInformation(content).............................................................................................597.2.7 Notification(Alarm)...............................................................................................................59

7.3 NONFUNCTIONALREQUIREMENTS..........................................................................................................607.3.1 SecurityRequirements...........................................................................................................607.3.2 AvailabilityRequirements......................................................................................................607.3.3 UsabilityRequirements..........................................................................................................607.3.4 EfficiencyRequirements.........................................................................................................61


/ 61

1. PURPOSE

Thisdocumentprovidesacomprehensivearchitecturaloverviewof thesystem,usinganumberofdifferentarchitecturalviewstodepictcertainaspectsofthesystem.Itisintendedtocaptureandconveythesignificantsecurity-relatedarchitecturaldecisionswhichhavebeenmadeonthesystem.

1.1 Scope Thescopeof thisdocument is todescribethesecuritydomains, trust levels, infrastructure-related

security, and the relationships among them. This document describes the overall architecture of theFlexmeter solution and refers to the supporting elements needed for functionality, and the architecturereferstothecohesivedesignoftheelements.

1.2 Definitions, Abbreviations and Acronyms

Abbreviations DescriptionHTML5 HyperTextMarkupLanguage

CSS CascadeStyleSheet

Activity Representsasinglethingthataperson/usercandoatatime.Severalactivitiesconnectedlogicallyformaprocess.

DataBase Representsasinglethingthataperson/usercandoatatime.Moreactivitiesconnectedlogicallyformaprocess.

Browser Isasoftwarethatallowstheposibilitytoaccessdifferentwebsites.

InternetInternational public network of computers which provides access tocomputing resources located on this network. The Internet can bedescribedasanetworkoflocalnetworksconnectedbyrouters.

SmartMeter Phisicaldevicetorecordandtransmitrealtimeinformationofconsumtion.MV/LVSubstation Medium/LowlevelpowerstationCRUD Create/read/update/delete

Userprofile Databaseregistrationwhereisdatakeeptaboutaregistreduser.Userid IdentificationdatabasenumeberforauserregistrationRoles Groupsofuserswithspecificpermissionsintheapplication

JRE JavaRuntineEngineistheplatformontowhichtheapplicationserverruns.

JMS JavaMessagingService


/ 61

2. ARCHITECTURAL REPRESENTATION

Thearchitectureofthesoftwaresolutionisstructuredintothreemaincomponents(Figure1):

• Presentationlayer• Businesslogiclayer• Databaselayer

2.1 Presentation layer Onthediagrambelowaredepictedthesoftware’sarchitecture,users interfaces,cloudapplication

anddatabases(Figure2).

Presentation layer

Business layer – Micro-service architecture

Database layer

Figure1Architectureofsoftwaresolution


/ 61

The Presentation Layer ( Figure 3) is made up from a collection of HTML5 web applications

independent of operating system and browser that allow access to all features of the system: useradministration, definition of assets and. Each component it is independent from other components andinteractswithservicesinthebusinesslogiclayer.

Each component from thepresentation layeroutputs content inHTML5 / CSS3and JS compliantwiththeW3Cstandards,inordertobedisplayedasdesignedinmostcommonbrowsers.

.

Application interface (Figure 4) is web-based, running on the client browser. The information is

updatedaccordingtotheuserrequests,creatingaflowsimilartodesktopapplicationsbyusingtechnologieslikeAngularJSandNodeJS.TheinterfacedesignoftheapplicationwilluseelementslikeBootstrap.

Presentation layer

User management

Assets Monitoring and control

Event management

Reports

Figure3-Representationlayerandapplicationcomponents

Figure2–Softwarearchitecure,userinterfaces,cloudapplicationanddatabases


/ 61

Figure4Userapplication

Eachusercanaccessprivatedataonlyaftertheauthenticationprocess.Theauthentication(Figure

5)willbebyuserIDore-mailaddressandpassword.Therearedistinctlevelofrolesandpermissionsfortheusers,eachuserbeingassignedtoarole.

Figure5Userauthentication

2.2 Business logic layer

2.2.1 Micro-services layer TheBusinessLogicLayer(Figure6)isresidentinthecloudandincludesalltheservicesnecessaryto

implementthefunctionalityofthesystem.ItisstructuredaccordingtoMicro-servicearchitectureforwhichthesystemisdecomposedintoacollectionofindependentandspecializedserviceseachofwhichexhibitingitsowninterfacetobeaccessedfromotherservicesofthesystemorcomponentsofthePresentationLayer.

Eachservicecanbemanagedindependentlyfordeploy/start/stopoperations.Inside the micro-service layer deployed and running services communicate trough a messaging

service.(Ex:JavaMessagingService-JMS)


/ 61

2.2.1.1 Benefits of micro-services Unlikemonolithicapplications,micro-service-basedapplicationscanbeselectivelyscaledout.Since

each micro-service is autonomous and independent, it is easy to monitor and replace a faulty servicewithoutimpactinganyother.

Themicro-servicedevelopmentcanbedoneinself-handlingapplicationanddeployedinthecloudarea.Eachmicro-servicecanbeupdatedwithoutimpactingtheothers.

Themainadvantagesofthemicro-servicesare:- The services are small - fine-grained to perform a single function (similar to the Unix

philosophyof"Doonethinganddoitwell").- Thedevelopmentcanincludeautomationofdeploymentandtesting.Thiseasestheburden

onmanagementandoperations.- Maintenanceofindividualservicesindependently.- Thedesignprinciplesshouldincludefailureandfaults,similartoanti-fragilesystems.- Theservicesareelastic,resilient,compostable,minimal,andcomplete.

Alltheseserviceswillbescalable,dependingontheload.Thecloudserviceswillberesponsibleforhorizontallyscalingtheservices.

User management Service

Assets Service

Event Management service

Reports Service

Monitoring and control service

Messaging system

Figure6Micro-servicearchitecture


/ 61

Figure7Web-servicecontainer

2.2.2 Service Layer Theweb-serverprovidestheinterfaceandprocessestherequestsfromtheusers.Theobjectiveisto

runandadministratethedeployedservices.Thecommunication layer (Figure8)providesprotocols forexchangingprocessing instructions that

have been initiated by users of thewebsite solution. The objective of interoperability at this layer is toachieveaseamless integrationofcommunicationsrelatingtotheinstructionsreceivedandfeedbackgiventotheusersofthewebsitesolution.

Figure8Servicelayer


/ 61

Eachservicecanhaveaconnectiontoalocaldatabasewhereuserdataiskeptandaconnectiontoanexternaldatabase,fromwheremeterdataisobtained(Figure9).UserprofileandmeterdataaremappedunderauniqueuserID.

Figure9Connectiontointernaldatabaseandexternaldatabase

2.2.3 Application general structure On the diagram below is represented the application general structure (Figure 10) taking into

account the connection with the IREN or E-on databases. The schema defines the main layers of theapplicationwiththesub-modulesandmicro-servicesthatdefinestheapplication.

Connectionbetween the layersof theapplication isdoneover the internet forpresentation layerandconnectionstothedatabases(IREN,E.on),insidedecloudforbusinesslayeranddata-connectionlayer.

Communication over the internet is done using theweb 2.0 standard, between presentation andbusiness layers, where presentation layer is composed of applications running on user devices that canprocessedthroughHTML/CSS/JS.Thepresentationlayerisbeakedinmodulesofapplication;eachmodulewithitsownpurpose.Modulesoftheapplicationcanshowdifferentinformationdependingontheroleoftheuser,somemodulesbeinghiddenforcertainroles.

Thebusiness layermodulesexecuteallthedataprocessing,operatingontheserversideonaJavaRuntimeEngine(JRE).Ontothislayersitsthedataconnectionlayertodatasources.


/ 61

Figure10ApplicationstructurewithelectricitydatabasesconnectionThemeterdataaggregationsystemwillprovideinformationtotheapplicationserver(Figure11)


/ 61

Figure11Dataaggregationstructure

Theapplicationstructurecanbeextendedwithconnectiontootherdatabases.Themaincondition

forotherconnectionsistoprovidethesametypeofdatatotheconnectionlayer.Thedataprovidedbythedatabasesconnectionscanbemappedbytheconnectionserviceontothe

localdatabases(Figure12).


/ 61

Figure12Applicationstructurewithelectricityandcoldwaterdatabasesconnection

Within the connection layer,multiple data sources can be added depending on the needs of theapplication’s user. This layer model of the data is mapped on the data coming through the databaseconnection,sothatallthedataprocessedinthebusinesslayerisconsistent.


/ 61

Data coming throughdatabase connection canbeprovided in a processedmanneror rawas it iscollected.Dataissentinchunksthatareprocessedatthebusinesslayerwithdifferentalgorithms.

Figure13Datamodel

The data model workflow is represented in Figure 13, which shows the connection betweencomponentsofapplication,useranddevices.


/ 61

Figure14Dataaggregationscheme

2.2.4 Java messaging service

TheJavaMessageService(JMS)APIisaJavaMessage-OrientedMiddleware(MOM)APIforsendingmessagesbetweentwoormoreclients.JMSisapartoftheJavaPlatform,EnterpriseEdition,andisdefinedbyaspecificationdevelopedundertheJavaCommunityProcessasJSR914.ItisamessagingstandardthatallowsapplicationcomponentsbasedontheJavaEnterpriseEdition(JavaEE)tocreate,send,receive,andreadmessages. Itallowsthecommunicationbetweendifferentcomponentsofadistributedapplicationtobelooselycoupled,reliable,andasynchronous.”

TheJMSservicefromthebusinesslayerimplementsthecommunicationfunctionbetweenservicesinside the applications and outside the application. The implementation of the JMS process can betechnologieslike“RabbitMQ”or“Mosquitto”.

Inside the web application – the JMS asynchronous messaging communication between micro-services,exchangedataintheformofmessages.

Outside the web-application – the JMS asynchronous messaging communication with outsideapplicationanddatagathering,dataispackedinmessages.EachmessagecanbegeneratedbydifferenttypeofapplicationandpushedontotheJMSfromthebusinesslayer(Figure14).

2.2.5 Application Message Broker


/ 61

Figure15MessageFlowinMessageBroker

The message broker system is an internal application service that is responsible with message

administration.Eachexternal applicationor service, like IREN / E.on’s, canaddamessage to themessagebroker

system queue. The internal services from the application will check for messages and process messagesaddressedtoanindividualservice.

Themessagebroker system isused similarlyby the internalmicro-services thatneed toexchangedata.

Eachmessagewillwait in thequeueuntil it isprocessedbya service.Dependingon themessagerequest,themessagecanincludearesponsetotheapplicationthatgeneratedit.


/ 61

Figure16Messagesflowforinternalservices

Internalmicro-servicesof theapplicationexchange informationthroughamessagebrokersystem.Eachmicro-systemcanbeasenderandreceiverofmessages.Messagesarestoredinthequeueuntileachsendergetsitsownmessagefromit.

.


/ 61

Figure17Messagetype

Messagesinthemessagebrokerqueuecanbeofdifferenttypesdependingontheapplication

thatgenerates:- Adatamodeltype,thisisspecifictothedatathatcamefromthedatabase.Thesemessages

containdataregardingthemeterregistration.- Anevent,thisisspecificforeventsinsideoroutsidetheapplication.A discussion on internal service application, this is a discussion between services inside the

application

2.2.6 Energy storage

The energy storage system is treated like any energy provider in the system. It connects throughdatabaselayerandcommunicateswiththemicro-servicesfromthebusinesslayerthroughmessagebrokersystem.


/ 61

Figure18Energystorage


/ 61

2.3 Presentation layer modules description

Figure19Presentationtoservicemodulecommunication

Each module from the presentation layer has an corresponding service module. Communication

betweenthemodulesisdoneovertheinternet.

2.3.1 User management The user management presentation module is responsible with generating the user interface

elements in order to manage the user internal application. This module runs on the authenticated usermachineandcommunicateswithservicemoduleformthebusinesslayer.

Figure20Usermanagementcommunicationwithservice

Inthelocaldatabaseaprofileforeachuseriscreatedandassigneduserassets.ThelistofusersinthesystemisrequestedfromtheuserserviceinIREN/E.ondatabases.(Figure21)


/ 61

Figure21Userlistprofiles

2.3.2 Assets Theassetmodulegeneratestheuserinterface(UI)inordertofacilitatetheassetmanagementfrom

theuseraccount.Thiscomponentrunsontheusermachineandcommunicateswiththeassetservicefromthebusinesslayer.

Figure22Assetsmanagementmodule


/ 61

Figure23UserAssets

Theuserassetsfromthelocaldatabasearecomposedofmultiplecomponents,oneofthemistheapplicationUIDinordertoassigndevicestotheuserprofile.

Foreachuserprofilethereisagatewayassociation.Thegatewayprovidesthelistofdevicesusedbyauser.(Figure24.)

Figure24AssetsGateways


/ 61

Theservicesaremappedforeachdevice.Asanassetadeviceismappedtoagatewayfromtheuserprofile. By getting a device, the application can access the services according to that device

Figure25Assets-Deviceswithservices

The user profile will have as basic information: user identification information, user location onbuilding,buildinggroup,assetsassignedtotheuser.

Theassetswillcontaintheapplicationinformation,gateway,deviceswithservices.

Figure26Userprofilewithassets


/ 61

2.3.2.1 Reports The reports will be generated on the date collected from the devices for each user. The data

computation is done by the report service, providing fast information from local database and liveinformationobtaineddirectlyfromIREN/E.ondatabases.

.

Figure27Reportsmodulecommunication

Thereportswillbegeneratedondatecollectedformdevicesforeachuser.Thedatacomputationis

doneby the reports service,providing fast information from localdatabaseand live informationobtaineddirectlyfromIREN/E.ondatabases

Figure28Reportsonthedevices

2.3.2.2 Monitoring and control Monitoringandcontrolmodule is responsiblewithgenerating theuser interface (UI)elements for

the user to monitor and control action in the user profile. This module runs on the user machine andcommunicateswithitsservicemoduleformthebusinesslayer.

Figure29Monitoringandcontrolcommunication


/ 61

2.3.2.3 Event management Theeventmanagementmodulerunsontheusermachineand is responsible togeneratetheuser

interface (UI) elements, in order for the user to manage the events on his/her profile. This modulecommunicateswiththeservicemodulefromthebusinesslayer.

Figure30Eventsmanagementcommunication

2.4 Business layer micro-services description

2.4.1 Connection between module and service Eachmodulefromthepresentationlayerhasacorrespondingservicemodule.Presentation layer module: creates the user interface objects, generates the user requests and

creates a visual display of data for the user. This module runs on the client machine (browser) andcommunicatesdirectlybyrequestswiththeservicemodule.

Business layermodule: runsontheserverside,managestherequests fromthepresentation layermoduleandperformsdataprocessingactions.

2.4.1.1 UsermanagementserviceThe user management service is responsible with the processing of the requests from the user

managementmoduleinthepresentationlayer.Thismodulerunsontheserverandoperatesallrequestsontheusersaccount/profile.


/ 61

Figure31Userprofileandassets

Eachuserprofilehasauniqueidentificationkeywitchindentifiesassetsassignedtotheuserprofile.Assetscanbeassignedonlytooneuserprofile,notwouserprofilescansharethesameasset.

2.4.1.2 Assets service Theassetservicerunsontheserversideandprocessesalltherequestsfromtheassetmoduleinthe

presentationlayer.


/ 61

Itprocesseseachassetwhichcamefromthemessagebrokersystem,identifiestheassetbyauniqueidentification key. The attached identification key is used to assign assets to a user profile

Figure32Assetworkflow

2.4.1.3 Reports service Thereportservicerunsontheserverside, itspurpose is toprocesstherequests fromthereports

moduleinthepresentationlayer,periodicallygeneratereports.Thisservicehasserverssub-services.Thesub-servicesrunspecifictasksatperiodictimes,inordertogeneratethereportsfortheusers.

Eachreporttask’sgenerateddatawillbestoredinthelocaldatabaseandwillbeuseduponuserrequesttothereportmodule.

Sub-services on the reports service runs like anymicro-service the only difference is that all therequestsaredoneinthereportsservice(Figure14).

Reportsservice’ssub-services:• NILM(NonIntrusiveLoadMonitoring)• EADRM(EnergyAggregatorDRModel)• LGFA(LoadandGenerationForecastingalgorithms)• DRA(DemandResponseAlgorithms)


/ 61

• TI.E

Figure33Sub-servicesformreportsservice

Each subservice processes the data on assets; the resulting processed data is packed in a

newassetwiththeuniqueidentificationkey.

2.4.1.4 Monitoring and control service Monitoring and control service runs on the server side, it processes all the requests from the

monitoringandcontrolserviceinthepresentationlayer.

2.4.1.5 Event management serviceTheeventservicemodulerunsontheserversideitspurposeistomanagealltheeventsgenerated

in the application, process the requests which came from the event management module and runsperiodicaltasks.


/ 61

Figure34Eventsprocesslevel

AlleventsintheapplicationoriginallycameasaJavamessageontheJavamessagingsystem.From

therethemessageisprocessedbytheeventmanagementservicedependingonthetypeofevent.Typeofevents:

- Internalevents:theseeventsaregeneratedinsidetheapplicationbyaserviceorbyanuser.- External events: these events are pushed on the message broker by one of the external

databaseconnection.Anytypeofeventisprocessedbyeventmanagementservice,fromheretheeventisshownonthe

presentation layer and sent via e-mail to the user (this may be optional, depending on applicationrequirements).

2.4.1.6 DatabaseconnectionlayerdescriptionThedatabaseservices(Figure35)havealocaldatabaseforstoringdataandtypesofconnectionto

remote databases or services from where data is collected. Connection service offers the possibility ofextendingthesources(connections)todatabyconfiguringanewdatabaseconnectiontype.

.


/ 61

Figure35Databaseconnectiontype


/ 61

2.5 Database layer

The database system (Figure 36) consists of relational databases with the possibility of multiple

connections with different user permissions. The database system offers the possibility of expansion byextendingthedatagatheringprocesstootherdatabases.

Thedatabaselayerinteractswiththeservicesfromthebusinesslayer.Eachmicro-servicefromthebusinesslayercanaccessadatabasethroughtheconnectionlayer.

Instances of thedatabases canbe locatedoutside the cloudor insidede clouddependingon therequirementsInstancesofthedatabasescanbe locatedoutsidethecloudor insidedeclouddependingontherequirements.

Figure36Databaseconnectionlayer


/ 61

2.5.1 Local database Thepurposeofthisdatabaseistoprovideafastconnectiontodataandinformationabouttheuser

profile, reportsandassets.Some informationneedsomeprocessing time, like reports. Inorder togiveaninstantaneous and live information, application reports service can provide data quickly from the localdatabaseswhileupdatingstoredreportswithcurrentinformationaccessedoverthedatabases’connectionlayer.

2.5.2 Users Thissectionofthelocaldatabasemanagestheuserprofileinsidetheapplication,generaldataabout

theuser,roleassignmentandpermissions.Userprofileiscomposedofbasicuserinformationlike:first/lastname,e-mailaddress,phonenumberandotherprofileinformation.

2.5.2.1 User roles

Role DescriptionConsumer DescribestheenduserpermissioninsidetheapplicationProsumer Is a type of end user with energy production capabilities (energy

storage)thisroleextendsthe“Consumer”.DSO Distributionsystemoperator - responsible forensuring the long-term

abilityof the system tomeet reasonabledemands for thedistributionofelectricity

Retailer Definestheuserwhichdeliverstheenergytotheenduser.

2.5.3 Reports Thissectionmanagesreportsgeneratedbytheapplicationupondataupdatescomingthroughthe

databaseconnectionlayer.Thereportsectionactslikeadatabufferforafastresponsetotheuser,duringthistimetheapplicationrequestsupdatesonthereportswithcurrentdata.

Thistypeofbehaviorinsuresinstantresultsfortheuser,keepingeventuallossofexternaldatabaseconnectiononlyatthebusinesslevel;databeingupdatedatperiodicaltimes.Sometypeofreportsrequiretimetoprocess,sobyusingliveupdatestheuserwouldexperiencelongwaits.

Atthislevelsometypeofreportsareupdatedwithoutgeneratingnewrecordingsonthedatabase.Ifanyprocessingalgorithms requirehistoricaldata this canbeprovideddirectly fromthe local sourceusingprocesseddata.

2.5.4 Assets Intheassetsectioniskeptinformationlinkedtotheuserprofile.Thissectionisrepresentedbythe

localdatabasesandtheexternaldatabase.Toachassetisaddedtheuseridentificationkey.


/ 61

3. BUSINESS INTERACTIONS

In the<FLEXMETER>project twopilotapplicationswillbe implemented in twodifferent countries(Italy andSweden),ona realdistribution systems,with the involvementof the localDSO’s andvolunteerprosumers. The figures below (Figure 37 and Figure 38) represent the interactions between the variousactorscoveredbythe<FLEXMETER>projectactivities.

3.1.1 IREN demo project Themonitoring applied over the Torino demonstrator is based on the collection of the followingphysicalquantities:

• ateachdwellinglevel:o overallelectricityconsumption;o energyrenewableproduction(atEnvPark);o thermalenergyconsumption(districtheating);o waterconsumption.

• ateachsubstationlevel:o electricityconsumption.

Figure37:IRENdemoproject


/ 61

3.1.2 E.ON demo project DemonstratorinMalmö-Hyllie,SwedenHyllieisMalmö´slargestdevelopmentarea.TheareaisapartofMalmöcitywhichisexpanding

rapidly,andwill inaperiodof5-10yearsholdapprox9000apartmentsandadditionalofficeandcommercialbuildings.ItisafocusareaalsoforE.ONtotakepartintheexpansionofthispartofthecity. In this area a fully-integrated infrastructure for electricity, heating and cooling is beingdeveloped,incorporatingasignificantproportionofdistributedenergygenerationtopromoteself-sufficiency.Smartgridtechnologywillbeusedtobalancesupplyandconsumptionandsmartenergymanagementfeatureswillbeincorporatedintobuildingsandindividualhomes.


/ 61

Figure38:E.ONdemoproject


/ 61

Description

Theprojectisaimedatcollectionofreal-timemeasurementdatafromthecustomer´sconsumptionmeters and to collect, store and present the data internally within E.ON but also to feed it tosolutionsabletopresentittothecustomersandmarketparticipantsasretailers.ThefocusfortheimplementationisE.ON´sflagshipproject“SustainableCityHyllie”andisaimingatatechnologytestofTCP/IPMeshRadioconnectedelectricitymeters.Thetechnologyisalsoabletocommunicate with other types of meters and other Smart Home devices communicating withIPv6/LowPAN.TheHyllieareaisapartofMalmöcitywhichisexpandingrapidly,andwillinaperiodof5-10yearsholdapprox9000apartmentsandadditionalofficeandcommercialbuildings.

During2014/2015itisexpectedtobebuiltapprox1500-2000apartments.However,thetestisincluding200meters.

Themainadvantageswiththistechnologyare:

• Open, standardized communication, both IPv6 and the web service interface is open(IEC61968)

• Robust, the technology isbasedonanautoroutingconceptwhere thenodescan find thecommunicationpaththemselves

• Expectedtobewidelyspread,itisthefuturesolutionalsoforotherSmartapplications

3.1.3 Limitations & Exclusions InScope

The applicationwill cover all the functional requirements described in “Functional Requirements”chapter.


/ 61

4. BUSINESS PERSPECTIVE

4.1.1 Business Objectives Objective Description

Flexiblesmartmeteringarchitecture The new metering system must provide acontribution to various objectives such as end-useraffordabilityofelectricity,energyandmarketefficiencyimprovement,CO2emissionandpollutantsreduction.

Real time and multi-service smartmetering

Oneof the<FLEXMETER>objective is todevelopacommunication technology exploiting a multi-serviceapproach,toensurereal-timeaccesstosinglemeter.

EnergystorageatDSO In order to overcome the problem of poweroutages,DSOhastheabilitytostoreenergy.

Detectionofenergythefts Detection of energy thefts is an innovative servicefortheDSOs.

Faultandoutagedetection Quasi-real-time grid level and user level faultdetection allowing optimal alarming and firstinterventionsystemstobeadopted.

Loadandgenerationforecasting From the energy distribution company viewpoint,benefits are related to the possibility of profilingcustomer energy behavior, in order to obtain a moreaccuratelyenergyforecastandadoptdemand-responsepolicies.

Userinterface Inthe<FLEXMETER>projectwillbedevelopauserinterfaceplatformwherewillbedisplayed informationaboutcurrentconsumptionforthefinalcustomer

Efficientaccesstoinformation: Easy&rapidaccesstocontent:• Usersshouldbeabletofindinformationquickly

andeasilythroughouttheapplication.Issecure The system must ensure that the following

(predefined)criteriawillbemet:

• Theintegrityandavailabilityoftheservices.• Authenticityandreliabilityofinformationprovided• Confidentialityofpersonalinformation


/ 61

4.1.2 Business success metrics The following business metrics are types/methods of measurement used to quantify the

performanceof thebusinessservices in termsofachieving theobjectivesproposedanddescribedaboveinthisdocument.

BusinessIndicator Definition

Numberofvisits TotalnumberofvisitstotheapplicationNumberofvisitsfrommobiledevices Totalnumberofvisits to theapplication

fromamobiledevicesSystemavailability Percentage of total time of service in one

year.Numberofsupportinquiries Total number of inquiries regarding content

orfunctionality(email,HelpDeks,etc.).Numberofusererrorsandtimeouts Numberoftimesusererrorsortimeouts

were handled (user displayed the errormessage,includingforloginreasons)

Notificationinrealtime(alarms) The alarm system shall notify theusers,in real time, about outage detection, faultdetection etc via the application or via smsorviaemail.


/ 61

5. BUSINESS CAPABILITIES DECOMPOSITION

5.1.1 Functional capabilities decomposition

Functionalcapability Description<Flexmeter>registration Being a demo project, user registration will be made by the

administrator.UserSign-in For accessing personal information, the system will have the

capabilityofusersign-in.Mobileview The applicationmust have amobile version of each page and

users must be able to use and complete any services describedaboveinthisdocumentusingthemobileversionoftheapplication.

Displayedinformation Oneofthepurposesofthe<Flexmeter>applicationistodisplaythe consumption in real time to the prosumers. The informationswhich an user can view are: history of consumption, periodicreports,consumptionforecasting,pricesandinvoices,alarmsetc.

Notification Theapplicationwillhaveanotificationsystemwhichwillinform(warn) theuseraboutdifferentproblems.Thenotificationscanbeofthefollowingtwotypes:systemnotificationandthoseaddedbytheapplicationbytheauthenticateduserwithroleofDSO.

SetPrices Throughtheapplication,theuserswithretailerrolewillbeableto establish a price for different types of utilities for a period oftime.Inthisway,theendusercanviewanestimatedcostfornextinvoice.

5.1.2 Non-functional capabilities decomposition

Non-functionalcapability

Description

Security The<Flexmeter>applicationmainsecurityobjectivesare:

• Confidentialityofpersonaldata• Integrityofdata• Availability(ofservicesproposedinthisdocument)• Authenticity• Reliabilityofcontent

Usability The <Flexmeter> application must follow the Internet designusability guidelines for the application as well as for the mobile.<Flexmeter> should consider usage of an adaptive layout for itspagesinordertooptimizethedisplayonanykindofdevice.


/ 61

Availability Availability of services should be 99% or superior at any time,24h/24h, 7d/7d, independently from performances of otherapplications.This leveltakes intoaccountmaintenanceoperations:specific maintenance operations or backup operations with ashutdown of the systemmay require a period of unavailability oftheapplication.

Efficiency (Scalability andPerformance)

Anapplicationprocessshouldneverwaitlongerthannecessary.Theapplication resources should be managed appropriately. Theapplication should be designed for commutability, reusability andinterchangeability.

Manageability &Maintainability

Software solution and all required software components shall beproperly documented. Any developed, customized component ortechnologypredefinedcomponentshallbedocumented.

Accessibility <Flexmeter> application should follow the guidelines from WebContent Accessibility Guidelines (WCAG) 2.0 and Authoring ToolAccessibility Guidelines (ATAG) 2.0 issued by theWorldwidewebconsortium(W3C).


/ 61

6. USER PERSPECTIVE

Insidethe<FLEXMETER>project,theproposedarchitectureofmeters(smartgrid)willallowtheinnovativeservicesthroughtheapplication,forprosumerandDSO,like:

• Prosumero Accessibledataandhistoricalrecordsoftheconsumption;o Analysisoftheelectricconsumptionwithsavingsuggestions;

• DSOo Faultdetection;o Detectionofenergythefts;o Networkbalancing;o Storageintegration.

6.1.1 User roles and profiles Inthenewapplication,thefollowingroleswillbeavailable:• Guestvisitors (or just“visitors”)–userswhichcanhaveaccessonly to theavailablepublic

application pages (About, Help and Contact)without authentication. The guest visitors areabletoaccessarticlesandresourcesconsideredasopen.

• Authenticatedusers–userswhichhaveloggedintheapplication:Ø Prosumers(enduser)–theapplicationwillhavemultipleprosumerusers(2000)that

willlogininordertoaccessapplicationsections:§ Dashboard–Theprosumercanselectoneoftheprovidersdisplayedonthe

dashboard(forelectricmeter,heatingmeter,watermeterandgasmeter)§ Each meter for different providers (electric meter, heating meter, water

meterandgasmeter)willdisplaynextinformation:• Realconsumptionatevery15minutes• Totalconsumption• Currentdayconsumptionchart• Consumptionhistorychart• Last4monthsreport• Invoices• Loadprofile• Alerts

Ø Retailer - In the demo application therewill be no evaluation on the retailer side,

becausewedon’thaveintheconsortiumaretailer.Retailercanaccess:§ Dashboard – Retailer can view only his information about prosumer’s

consumption. In dashboard, he can view current day consumption, totalconsumption,consumptiononthelast3daysandachartaboutcurrentdayconsumptionateveryhour.

§ Overviewabouttotalconsumption–Retailercanview:• Realtimeconsumptionatevery15minutes• Totalconsumption• Currentdayconsumptionchart• Consumptionhistorychart


/ 61

• Last4monthreport§ Substationsconsumption–Retailercanselectasubstation inorder toview

thesubstation’sconsumption:• Realtimeconsumptionatevery15minutes• Totalconsumption• Currentdayconsumptionchart• Consumptionhistorychart• Last4monthreport• A chart which will contain information about Substation total

consumption / Total consumption for buildings associated toselectedsubstation/Totalconsumptionforprosumersassociatedtoselected substation. Total consumption must be equal, otherwiseDSOcanseeifsomethingiswrong.

§ Buildingsconsumption–Retailercanselectasubstationinordertoviewthesubstation’sconsumption:

• Realtimeconsumptionatevery15minutes• Totalconsumption• Currentdayconsumptionchart• Consumptionhistorychart• Last4monthreport

§ Prosumersconsumptionandinvoices§ Alerts–Retailercanseesystem’salertsorhecanaddone.§ Prices – Retailer can add prices for different period so that prosumer can

estimatehisinvoice.

Ø DSO (Distribution System Operators) – the system will have multiple DSO users

which can authenticate in the application in order to access the next applicationsections:

§ Dashboard – DSO can view only his information about prosumer’sconsumption. In dashboard, this type of user can view current dayconsumption,totalconsumption,consumptiononthelast3daysandachartaboutcurrentdayconsumptionateveryhour.

§ Overviewabouttotalconsumption–DSOcanview:• Realtimeconsumptionatevery15minutes• Totalconsumption• Currentdayconsumptionchart• Consumptionhistorychart• Last4monthreport

§ Substations consumption – DSO can select a substation in order to viewsubstation’sconsumption:

• Realtimeconsumptionatevery15minutes• Totalconsumption• Currentdayconsumptionchart• Consumptionhistorychart• Last4monthreport

• Buildingsconsumption–DSOcanselectasubstationinordertoviewsubstation’sconsumption:

Ø Realtimeconsumptionatevery15minutesØ Totalconsumption


/ 61

Ø CurrentdayconsumptionchartØ ConsumptionhistorychartØ Last4monthreportØ AtableTotalconsumptionforselectedbuilding/Totalconsumptionforprosumers

associatedtoselectedbuilding.Totalconsumptionmustbeequal,otherwiseDSOcanseeifsomethingiswrong.

• Prosumersconsumption• Alerts–DSOcanseesystem’salertsorhecanaddone.

Ø Softwareadministrator–TheapplicationwillhaveaSoftwareAdministratoraccount

(orjust“administrator”).Thesoftwareadministratorisinchargeofmaintaininganddeveloping the application. To do so, he/sheworks to define the architecture andtreestructureoftheapplication,takingintoaccountthedesign,navigation,graphicalstandards,andcontentaspects.Thesoftwareadministratorisresponsibleoncontentpermanent deletion and, if needed, content management. The softwareadministrator is in charge of carrying out or coordinating IT development forupgradingormaintainingtheapplication.Regardingusermanagement,thesoftwareadministrator is in chargeofmoderator approval andhe can createuser accounts.The software administrator will have full rights on all the application features.Nevertheless,thesoftwareadministratormightperformothertasksspecifictootherapplicationrolesifthisrequestisclearlyexpressedbytheContractingAuthority.


/ 61

7. FUNCTIONAL AND NON FUNCTIONAL REQUIREMENTS

7.1.1 Layout presentation Inthefollowingarepresentedthelayoutsforthefunctionalitiesidentifieduntilthismomentin

theproject.

7.1.2 Sign In page layout


/ 61

7.1.3 Dashboard for Prosumer Account


/ 61

7.1.4 Electric meter for Prosumer Account


/ 61

7.1.5 Alerts for Prosumer Accounts


/ 61

7.1.6 Personal Information for Prosumer Accounts


/ 61

7.1.7 Dashboard for DSO Account


/ 61

7.1.8 Overview for DSO Account


/ 61

7.1.9 Buildings Profile


/ 61

7.1.10 Prosumers profile


/ 61

7.1.11 Alerts display for prosumers


/ 61

7.1.12 Profile for DSO


/ 61

7.1.13 Dashboard for retailer Account


/ 61

7.2 Functional requirements

7.2.1 Registering in the Application Req.ID Description

FR-01-001 Takingintoaccountthespecificityofthisapplicationalluserswillbeimportedintheapplication.

7.2.2 User Sign-In Req.ID Description

FR-02-001 Aslongasanon-identifieduserisbrowsingthroughthepagesoftheapplication,<FLEXMETER> application display the Sign-In button in the header of allapplicationpagesandprovidetheuserwiththeabilitytosign-in.

FR-02-002 Iftheuserrequeststosign-in,<FLEXMETER>applicationdisplaytheSign-Inpagewithfollowingoptions:

• Sign-in

• Forgottenpassword

FR-02-003 <FLEXMETER>applicationasktheuserforthefollowinginformationintheSign-Inpage:

• Username(Mandatory–Textinput).

• Password(Mandatory–Textinput).

inordertoidentifytheuserintheproject.FR-02-004 Aftertheuserisrecognizedbythesystem,<FLEXMETER>applicationdisplay

thedashboardandlog-outbuttonintheheader

FR-02-005 As long as the user is not signed-in AND as soon as the user requests toretrievetheforgottenpassword,<FLEXMETER>applicationdisplaytheForgottenpasswordpageaskingtheuserthefollowinginformation

• UserE-Mailaddress(Mandatory–Textinput)

After the user has specified the e-mail address and submits the forgottenpasswordform,<FLEXMETER>applicationshallsendanemailwiththepasswordresettotheuser.

7.2.3 Homepage (Dashboard) Req.ID Description

FR-03-001 <Flexmeter>applicationdisplayalltypeofutility


/ 61

7.2.4 Header Req.ID Description

FR-04-001 As longas the registereduser isbrowsing/navigate through theapplicationpages, <FLEXMETER> application provide the user with the ability to accesscommonfunctionalitiessuchas

• Dashboard• Userprofiledata• Logout• Aboutpage• Contactpage• Helppage

directlyfromthenavigationzoneoftheapplication.

7.2.5 Navigation Req.ID Description

FR-05-001 Aslongastheuserisnavigatingthroughtheapplicationpages,<FLEXMETER>application provides the user with the ability to navigate to the dashboarddirectly.

FR-05-002 As long as the registered user is navigating through the application pages,<FLEXMETER>applicationprovidestheregistereduserwiththeabilitytologoutfromthesystem.

FR-05-003 As long as the registered user is navigating through the application pages,<FLEXMETER>applicationprovidestheregistereduserwiththeabilitytoaccesstheProfilepage.

FR-05-004 As longas theregistereduserwithprosumerrole isnavigating throughtheapplication pages, <FLEXMETER> application provides the registered user withtheabilitytoaccessOverviewpageforeachtypeofutility.

FR-05-005 As long as the registered user with prosumer or DSO role is navigatingthroughtheapplicationpages,<FLEXMETER>applicationprovidestheregistereduserwiththeabilitytoaccessProfilepage.

FR-05-006 As long as the registered user with prosumer or DSO role is navigatingthrough the applicationpages, <FLEXMETER>provides the registereduserwiththeabilitytoaccessAlertspage.

FR-05-007 AslongastheregistereduserwithretailerorDSOroleisnavigatingthroughtheapplicationpages,<FLEXMETER>providestheregistereduserwiththeabilitytoaccessSubstation’sinformationpage.

FR-05-008 AslongastheregistereduserwithretailerorDSOroleisnavigatingthroughtheapplicationpages,<FLEXMETER>providestheregistereduserwiththeabilitytoaccessBuilding’sinformationpage.

FR-05-009 AslongastheregistereduserwithretailerorDSOroleisnavigatingthroughtheapplicationpages,<FLEXMETER>providestheregistereduserwiththeabilitytoaccessProsumer’sinformationpage.

FR-05-010 Aslongastheregistereduserwithretailerrole isnavigatingtheapplicationthrough pages, <FLEXMETER> provides the registered user with the ability toaccessPricepage.


/ 61

7.2.6 Access to Information (content) Req.ID Description

FR-06-001 As longas theregistereduserwithprosumerrole isaccessinghis/heraccount,theapplicationwilldisplayapagewhereallutilitygeneralinformationare.

FR-06-002 If registereduserwithprosumer role is accessing the information fora specificutility,theapplicationwilldisplayallinformationaboutthatutility

FR-06-003 IfregistereduserwithprosumerroleisaccessingtheAlerts/Notificationlinkfromnavigationzone,theapplicationwilldisplayalltypeofalerts(availableandalertshistory)

FR-06-004 If registered user with prosumer/DSO/retailer role is accessing the Profile linkfromnavigationzone,theapplicationwilldisplaypersonalinformation.

FR-06-005 As long as the registered user with DSO/Retailer role is accessing his/herAccount,theapplicationwilldisplayapagewhereisutilitygeneralinformation.

FR-06-006 As long as the registereduserwithDSO role is accessing theAlert/Notificationlinkfromnavigationzone,theapplicationwilldisplayalltypeofalerts(availableandalertshistory).Fromthissection,DSOcanaddalertsforaperiodoftime.

FR-06-008 AslongastheregistereduserwithDSOroleisaccessingtheSubstationlinkfromnavigationzone,theapplicationwilldisplaydeinformationaboutallsubstations.DSOcanchoosetoviewinformationforonesubstation.

FR-06-009 AslongastheregistereduserwithDSOrole isaccessingtheBuildings linkfromnavigation zone, the applicationwill display de information about all buildings.DSOcanchoosetoviewinformationforonebuilding.

FR-06-010 AslongastheregistereduserwithDSOroleisaccessingtheProsumerlinkfromnavigationzone,theapplicationwilldisplaydeinformationaboutallprosumers.DSOcanchoosetoviewinformationforoneprosumer.

7.2.7 Notification (Alarm) Req.ID Description

FR-07-001 <FLEXMETER> shall provide user awareness about utilitieswhichwill notifytheprosumerviatheapplicationORviasmsORviaemail.

FR-07-002 <FLEXMETER> shall provide an automatically outage detection which willnotifytheDSOviatheapplicationORviasmsORviaemail.

FR-07-003 <FLEXMETER> shall provide authenticateduserwithDSO role the ability tosetalarmforprosumer.


/ 61

7.3 Non Functional requirements

7.3.1 Security Requirements Req.ID Description

NFR-01-001 <FLEXMETER>shallgrantuseraccesstodifferenttoolsandsectionsoftheportalonly after user authenticates and authorization to each feature is validated.(authenticationandauthorizationmechanism)

NFR-01-002 <FLEXMETER> shall grant access to restricted areas, like the administrationconsole only through an SSL connection by redirecting the user to an HTTPSconnectionifnotalreadyusingone.

NFR-01-003 <FLEXMETER> shall mitigate all known security risks related to search boxscenarios.

NFR-01-004 CAPTCHAor the similar security control implemented in <FLEXMETER> shall bebasedonthelatestavailabletechnologyinordertoavoidanyspamorautomaticregistration

NFR-01-005 <FLEXMETER>shallensurethenon-repudiationaspectofsentnotifications.NFR-01-006 <FLEXMETER> shall include prevention for the following threats typical for

websites:

• Injection• Cross-SiteScripting(XSS)• BrokenAuthenticationandSessionManagement• InsecureDirectObjectReferences• Cross-SiteRequestForgery(CSRF)• SecurityMisconfiguration• InsecureCryptographicStorage• FailuretoRestrictURLAccess• InsufficientTransportLayerProtection• InvalidatedRedirectsandForwards

7.3.2 Availability Requirements Req.ID Description

NFR-02-001 Availability of services should be 99% or superior at any time, 24h/24h,7d/7d, independently fromperformancesofotherapplications. This level takesintoaccountmaintenanceoperations:specificmaintenanceoperationsorbackupoperationswithashutdownofthesystemmayrequireaperiodofunavailabilityoftheapplication.

7.3.3 Usability Requirements Req.ID Description

NFR-03-001 <FLEXMETER> main navigation shall be persistent and consistent on all webpages.

NFR-03-002 <FLEXMETER> shall match the design of themenu to the design of the entirewebsite.


/ 61

NFR-03-003 <FLEXMETER>shalldisplay in theheader thecorporate imageof<FLEXMETER>projectacrossallpages.

Theheadershouldidentifytheprojectacrosseachwebpage.NFR-03-004 As long as the user is viewing the home page, <FLEXMETER> shall provide the

userwithagoodoverviewofthewebsitecontentandfunctionalities.NFR-03-005 Thehomepageshallhelptheusertoefficientlyaccomplishthetoptaskswhich

areeasyaccessorreuseofanyinformation.NFR-03-006 The home page shall be kept clean of any links and content which could

distracttheuserfromthetoptasks.NFR-03-007 <FLEXMETER>mustfollowusabilityguidelinesNFR-03-008 <FLEXMETER>mustfollowMobileWebUsabilityguidelines

7.3.4 Efficiency Requirements Req.ID Description

NFR-04-001 <FLEXMETER>isexpectedtoperforminperfectconditionsforthefollowingserviceload:

• Atotalof2000multi-metersbothinMalmoandTurin

NFR-04-002 After the user requests to view the homepage, <FLEXMETER> shall displaytherequestedpageinnomorethan1second.

NFR-04-003 After the user submits the simple search form, <FLEXMETER> shall displaythesearchresultsinnomorethan2seconds.(average)

(This must take into consideration time took by the system to display therelatedpages)

NFR-04-004 After the user requests to view any web site page except the homepage,<FLEXMETER>shalldisplaytherequestedpageandtheassociatedcontentinnomorethan2seconds.

NFR-04-005 <FLEXMETER> shall provide caching and replication: to ensure highperformanceinpublicenvironmentscharacterizedbyspikesindemand.

d1.3 flexmeter report on platform requirments data...

Documents