Page 1
REFERENCEARCHITECTURE&DESIGNPRINCIPLESEIPSCCWORKSTREAM2–MAINDELIVERABLESEPTEMBER27,2017
FINAL,version1.00Maineditors:LutzHeuser,JeroenScheer,PieterdenHamer,BartdeLathouwerContributors:LutzHeuser,JeroenScheer,PieterdenHamer,BartdeLathouwer,AndyCox,PeterParslow,BernhartKempen,EvaKlien,JoachimLonien
ThisdocumentispartoftheoverallprogramEIPSCCOpenUrbanPlatforms,andisproducedbySupplySideWorkStream2,andbytheHorizon2020Espressoproject.
Page 2
2 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
EXECUTIVEABSTRACTTheEuropeanInnovationPartnershiponSmartCitiesandCommunities(EIPSCC)isastakeholderdriveninitiativestimulatedandsupportedbytheEuropeanCommission.TheEIPSCChasdefinedkeypriorityareaswhichwillbeaddressedthroughsixActionClustersincluding“IntegratedInfrastructures&OpenData”.Ageneralobservationisthatopenurbanplatformsareapre-requisitetosupportfasttake-upofsmartsolutionsincitiestoallowmanystakeholdersofacitytoparticipateandfordifferentvendorsolutionstobeeasilyintegrated.ThishasstimulatedaMemorandumofUnderstandingandourgoalistogainbroaderindustry,cityandothersupport,andtomoveforwardasacommitmentwithintheEIP.ThemarketforcurrentUrbanPlatform(s)isfragmentedanduncertainonthedemand-sideandlackinginteroperabilityandcommonstandardsinthesupply-side.TheintentoftheReferenceArchitectureanditsbelongingDesignPrinciplesistoprovidecitiesandcommunitiesthatwishtoimplementSmartCity&Communitiesinitiativesatrulymissionandvendoragnosticapproachthatwillresultinanenhancedinteroperable,standards-basedarchitectureandimplementationwhichisspecifictoamissionwhentheirspecificcitycontextisapplied.Inaddition,thisReferenceArchitecturecanbeusedwithexistingarchitecturestoplanforimprovinginteroperabilitymaturityandfunctioningofanexpandingtechnologysolutionforsmartcityinitiatives.Thismissionandvendoragnosticapproachismeanttoprovidekeyelementsandconceptsneededtobeaddressedtomaketheseresultingsolutionarchitecturesinteroperable.Thepurposeofthisworkistoprovideguidanceanddirectiontostakeholders(includingtheSmartCityandCommunitiesinitiatives)onthebetteruseofReferenceArchitecturesforguidingandconstrainingarchitecturedescriptions,developments,andusagesforcurrentandfuturecapabilities.Thekeypointsmadeinthisdocumentare:
• ReferenceArchitectureisdefinedasanauthoritativesourceofinformationaboutaspecificsubjectareathatguidesandconstrainstheinstantiationsofmultiplearchitecturesandsolutions.ThisdefinitionisapplicabletoallofSmartCityandCommunitiesinitiatives.
• Project-specificArchitecturesmaybedevelopedbyvariousorganizationsfortheirownpurposesandintendeduses,butthisReferenceArchitecturemustcontainthevariouselementsdescribedinthisdocument.
• ThegoalsandobjectivesofReferenceArchitecturearenumerous.Theysolveaspecific(recurring)probleminaproblemspace;explaincontext,goals,purpose,andproblembeingsolvedincludingwhenandhowReferenceArchitectureshouldbeused;andprovideconcepts,elementsandtheirrelationshipsthatareusedtodirect/guideandconstraintheinstantiationofrepeatedconcretesolutionsandarchitectures.
OpenUrbanPlatformsformacorebuildingblockbywhichcitiesbettermanagethecurrentexplosioninvolumesofcitydataandmoreeasilysharethisdatabetweencityservicesinordertoimproveoutcomesforsociety.Inourvision,SmartCitieshavekeycomponentsofinfrastructureandservices–environmental,emergencyresponse,trafficandenergymanagementtonameafew–integratedinsuchawaythatfeaturesandapplicationscaneasilybecombinedwithwhatevercapabilityexistedbefore.Achievingthatvisionrequiresmovingbeyondmanycurrentimplementationsinwhichthedegreeofintegrationofcoresubsystemswithinsmartcitiesisoftenlimitedbypatchworksoflegacyandfixedsolutionsconnectedbycustomintegrations,ifany.Therefore,wehavethewishtocreateanopen,referencableandcomposableSmartCity(Urban)Framework.Specifically,wedonotaimtocreateasingleormonolithicurbanplatform,sincethatwouldsuggestthatonesingleplatformshouldbethesolution.Rather,weexpectthatmultiplesystemswillariseandbeimplemented,basedona
Page 3
3 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
standardwayofworkingwithcomponentsthatadheretoopenstandards,patternsandreferences,thattogethergiveshapetoanopenurbanplatform,whichisthereforemorealogicalthanatechnicalentity.By‘composable’weimplythatcontinuousintegrationandimprovementwillbeachievedthrougheasyadditionoffunctionasopposedtowholesalereplacementorretrofitting.Citiesintegratingeachnewcapabilityshouldbeabletosimplyacquireandaddittotheexistinginfrastructurewithaminimumoftailoringandreworkofexistingcomponentinterfaces.Thiswillresultinsynergeticeffects,with‘thewholewillbegreaterthanthesumofitsparts’.WS2hasadoptedthegloballyacceptedandmostwidelyusedTOGAFFrameworkasstandardArchitecturalFramework.TheuseoftheTOGAFarchitecturalframeworkresultsinarchitecturesthatareconsistent,respondtostakeholdersneeds,adoptsandemploysbestpractice,andgivestheappropriateconsiderationtothecurrentandfuturerequirementsofagivenenterprise.Therefore,TOGAFprovidesbothtoolsandmethodsforthe“acceptance,production,use,andmaintenanceofanenterprisearchitecture”(TOGAF9.1).WedefineaReferenceArchitectureasfollows:
“Areferencearchitecturemodelstheabstractarchitecturalelementsinthedomainofinterestindependentofthetechnologies,protocols,andproductsthatareusedtoimplementaspecificsolutionforthedomain.”
OurvisionistohaveaReferenceArchitecturethatistrulymission,projectandvendoragnostic.Itthereforemaynotcontainanyformoftechnicalitiesnorsolutionelements,normayitbeprescriptiveorexcludingcertainsolutions.Itmustbeabletoactasarealreferenceforcitiesandcommunities,andotherrelevantstakeholders,thathavethewishtorealizeacomprehensivesolution,oronlypartofit.Wehaveformulatedthefollowingarchitecturalvisionstatement:
RegardingtheArchitectureGovernance,WS2doesnotmakeanystatements,sinceeveryproject,city,initiativewillfollowitsowngovernance.However,WS2promotesasoundgovernance,especiallywithregardstotheuseoftheestablishedReferenceArchitecture&DesignPrinciples.ThemainpartofthisdocumentisdedicatedtothedescriptionoftheReferenceArchitectureandDesignPrinciples.Todothis,wehaveselectedanumberofarchitecturalproductsthatfitourgoalsandneedsinthecurrentcontext.First,weintroduceaso-calledcapabilitymap,whichinTOGAFtermsisconsideredtobepartofthe‘businessarchitecture’,implyingthatthecapabilitymapismoreaboutspecifyingwhatisneededfromaSCCperspective,andnotfromatechnologicalperspective.Thecapabilitymapisseenhereasthecoreoftheopenurbanplatformarchitecture–thecommonframeworkthatprovidesasharedvision,structureandterminologyforallrelevantstakeholders.Afterdescribingthecapabilitymap,weproceedbyidentifyinganumberofdesignprinciples(andpatterns)andprovideinputformorecity-specificarchitecturewhich-followingTOGAF-wecall‘informationsystemsarchitecture’,withspecialfocusonunderlyingdataandapplicationarchitecture.
Page 4
4 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
AnOpenUrbanPlatformischaracterizedhereasfollows:• Theimplementedrealizationofalogicalarchitecture/content/designthatbringstogether(integrates)dataflowswithinandacrosscitysystems;
• exploitingmoderntechnologies(sensors,cloudservices,mobiledevices,analytics,socialmediaetc.);
• providingthebuildingblocksthatenablecitiestorapidlyshiftfromfragmentedoperationstoincludepredictiveeffectiveoperations,andnovelwaysofengagingandservingcitystakeholders;
• inordertotransform,inawaythatistangibleandmeasurable,outcomesatlocallevel(e.g.increaseenergyefficiency,reducetrafficcongestionandemissions,create(digital)innovationecosystems).
Capabilitiesrepresentwhatacityorcommunitydoestoexecuteitsmissionanddeliverservicesthatmeettheneedsofcitizensandotherstakeholders.Acapabilityisanabstractrepresentationofwhatisneededtoproduceanoutcomebyanorganizationorotherhumancollectives–alongwithgoalsandmetricsforthatoutcome.Capabilitiescanactuallybeimplementedbylinkingthemtorequiredpeople,processes,technology,informationandassets.Alternatively,capabilitiescanbelinkedtooneormore‘services’thattogether‘realize’acapability.SuchservicesmayincludeITapplicationservices,technicalservices,externalservices,andsoon.Capabilitiescanbelinked(withmany-to-manyrelationships)toorganizationalprocesses,services,people,departmentsandsoon,includingITapplications(ormodulesthereof).WithinthescopeofscopeofEIPSCCOpenUrbanPlatforms,10capabilitycategorieshavebeendefined:
Foreachcategoryasetofcapabilitieshasbeenidentified.Thesearepresentedinthepicturebelow.
Page 5
5 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Inadditiontoexistingandgenerallyavailabledesignprinciples,WS2hasidentifiedthefollowingadditionaldesignprinciplesinthecontextofopenurbanplatforms.
1. Alayeredapproachtowardsarchitectureisdesirable,toensureacommonandvaluabledecompositionoflogicalclusters,withinandbetweenstandardizationmusttakeplace,usingthePivotalPointsofInteroperability(PPI)
2. Applications(ormodulesthereof)withintheopenurbanplatformmustbelinkedtothecapabilities(possiblywithmany-to-manyrelationsbetweencapabilitiesandapplications/modules)asspecifiedinthecurrentreferencearchitecture,toe.g.promoteconsistency,preventoverlapandsupportknowledgeexchangeorevenre-useacrosscities.
3. Thearchitectureoftheopenurbanplatformshouldallowandcertainlynothinderincremental,iterativeevolutionaryapproachesforimplementationofopenurbanplatforms,typicallystartingbyfocusingonexistingopportunities/painpointsandthenincrementallyfurtherexpandingtheplatformovertime.
4. Openurbanplatformsshouldbebasedasmuchaspossibleonopenstandards,preferablybasedonlarge-scaledeployments.Especially,betweenthevariouslayersinanurbanplatform,standardsarepromotedtosupportflexibilityandprevente.g.vendorlock-inn(allowingscenariosinwhichmultiplevendorssupplydifferentpartsormodulesoftheplatform,thatstillworktogetherwithoutrequiringcustomization).
5. Modularity:thearchitectureoftheopenurbanplatformshouldenablecitiestouseanddeployvarious(combinations)ofmodulesor‘components’intheopenurbanplatform,notrequiringacomplete‘bigbang’implementationofanopenurbanplatform.
6. OpenUrbanplatformsmustbeabletointegratewithbothnewandexistingsystems(e.g.includingsmartcitysolutionapps/applicationsthatarebuiltontopoforuseservicesprovidedbytheopenurbanplatform,e.g.includingcommunication/IoTsystemsorsensornetworks)takingintoaccountthatinmostcasesthereisno‘greenfield’.
7. Openurbanplatformsshouldfocusoninteroperability(dataformats,protocols)betweenthevariousdefinedlayers,andnotsomuchwithincertainlayers
8. Privacy&Securityareintegralpartofanyopenurbanplatformandtheirarchitecture(P&SbyDesign)
9. Apace-layeredapproachispromoted(i.e.recognizingthatsomemodulesorcertainlayerschangefasterthanthoseinotherlayers)
10. Urbandataiscurrentlyoftenunder-utilized,andthenofteninasingleverticalapplication.Despitesynergeticopportunities,dataishardlyusedacrossverticaldomains.Animportantfocusareaofurbanplatformsshouldthereforebeonharmonizationofdatafromdifferentdomainsanddatalogistics
11. UrbanPlatformsshouldpromoteandfacilitatethepublicationof(Linked)OpenData.12. Animportantfocusareaofurbanplatformsshouldbeon‘collaboration’and‘sharing’
processesacrossdomainsvs.“singleentity/domainprocesses’Lookingatthecapabilitymapandprinciples,wehaveidentifiedseveralDesignPatternsthatwillsupportmoreefficient,coherentand/orstandardizeddeploymentofsolutions.TheseDesignPatternsfocusmainlyondataandinteroperability,reflectingthemainfocusareasofanopenurbanplatform.Theintentionoftheprojectandreferencearchitectureistobevendorandprojectagnostic,notprescribinganyspecifictechnology,productorsolution.Therefore,topreventanyunintendedpreference,werestrainourdescriptionofaninformationsystemsarchitectureinthiscontext,andlimitourselvestoconsiderations,recommendations,examplemodelsandotherartefacts,asinputforcitiesandcommunities(orsuppliersandserviceproviders)toproducetheirowninformationsystemarchitecture.
Page 6
6 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Ingeneral,theinformationsystems(solution)architectureisconsideredhereasadesignofthetechnologyrequiredforrealizingtheopenurbanplatformcapabilitiesasdescribedbeforeinthischapter.Pleasenotethatinordertorealizecapabilities,technologyaloneisnotenough–technologiesmustbeembeddedwithinprocessesandbemadeavailableforpeoplethatuse,manageorplayotherrolesthatarenecessarytorealizeacapability.Inaddition,itshouldbenotedthatnotallcapabilitiesarenecessaryineachandeverySCCcontextduringalltimes.Rather,werecommendaphasedandincrementalapproach.Thisimpliesthattheinformationsystemsarchitecture,likeeverythingelserequiredtofulfillcapabilities,isnotastaticcollectionofartefacts,butmustbeadaptedovertimeandwitheachincrement,ascapabilitiesarebeingaddedtoacontextspecificopenurbanplatform.Also,importantly,theinformationsystemsarchitecturedoesnotnecessarilycorrespondtoasinglesystem.Infact,itismuchmorelikelyinpracticethatanopenurbanplatformanditscapabilitiesarerealizedbyavarietyofsystems.Thesemayincludenewlybuiltsystemsorexistingsystemsthatareadaptedtobecomepartoftheoverallopenurbanplatform,thelatterineffectbeinga‘systemofsystems’.TheInformationSystemsArchitectureisconsideredfromtwoperspectivesandcorrespondingarchitecturesthatshouldbemostprominentinanyinformationsystemsarchitectureofanopenurbanplatform:thedataarchitectureandtheapplicationarchitecture...//
Page 7
7 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
TABLEOFCONTENTSEXECUTIVEABSTRACT...........................................................................................................................2TABLEOFCONTENTS.............................................................................................................................7LISTOFFIGURES....................................................................................................................................8LISTOFTABLES......................................................................................................................................91.INTRODUCTION...............................................................................................................................10
1.1TARGETAUDIENCE................................................................................................................................101.2PURPOSE.............................................................................................................................................111.3VALUEOFAREFERENCEARCHITECTURE.....................................................................................................111.4DOCUMENTSTRUCTURE/READINGGUIDANCE..........................................................................................12
2.CONTEXTANDBACKGROUND..........................................................................................................132.1SCOPEOFEIPSCCOPENURBANPLATFORMS............................................................................................142.2ONECOMMONFRAMEWORKFORARCHITECTURE........................................................................................15
3.ARCHITECTUREVISION....................................................................................................................183.1REFERENCEARCHITECTURESTAKEHOLDERVALUE.......................................................................................183.2FOUNDATIONALPRINCIPLESANDASSUMPTIONS.........................................................................................193.3LINKSWITHOTHERINITIATIVES................................................................................................................21
4.REFERENCEARCHITECTURE..............................................................................................................224.1INTRODUCTION.....................................................................................................................................22
CharacterizationofanopenUrbanPlatform....................................................................................234.2OPENURBANPLATFORMCAPABILITYMAP................................................................................................23
Capabilitiesexplained.......................................................................................................................23Capabilitycategories........................................................................................................................24Capabilitymap..................................................................................................................................25Capabilitiespercategory..................................................................................................................26
4.3OPENURBANPLATFORMDESIGNPRINCIPLES.......................................................................................394.4OPENURBANPLATFORM-INFORMATIONSYSTEMSARCHITECTURE.........................................................41
DataArchitecture.............................................................................................................................43Datamodel.......................................................................................................................................45Datavaluechain...............................................................................................................................49ApplicationArchitecture...................................................................................................................52
APPENDIXA.ACRONYMS....................................................................................................................58APPENDIXB.REFERENCEARCHITECTURECAPABILITYMAP–LARGEVIEW..........................................59APPENDIXD.DOCUMENTMETADATA.................................................................................................60
B1.REVISIONHISTORY.................................................................................................................................60B2.STATEMENTOFORIGINALITY...................................................................................................................60B3.DISSEMINATIONLEVEL...........................................................................................................................60
Page 8
8 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
LISTOFFIGURESFIGURE1.EIPSCCINITIATIVES....................................................................................................................................13FIGURE2.SCOPEOFEIPSCCOPENURBANPLATFORMS..................................................................................................14FIGURE3.TOGAFFRAMEWORK.................................................................................................................................16FIGURE4.WS2SCOPEPLOTTEDONTOGAFENTERPRISECONTINUUM..............................................................................17FIGURE5.ARCHITECTUREVISIONEIPSCCOPENURBANPLATFORMSWS2REFERENCEARCHITECTURE&DESIGNPRINCIPLES.....20FIGURE6.ROADMAPANDINTERDEPENDENCIESWITHOTHERINITIATIVESANDWORKSTREAMS.................................................21FIGURE7.OVERALLEIPSCCOPENURBANPLATFORMCAPABILITYMAP–OVERALLLEVEL.....................................................25FIGURE8.EIPSCCOPENURBANPLATFORMCAPABILITYMAP–CATEGORYLEVEL................................................................26FIGURE9.ARTEFACTSASSOCIATEDWITHTHECORECONTENTMETAMODELANDEXTENSIONS.................................................42FIGURE10.COMMONOPERATINGMODELFORDATA......................................................................................................44FIGURE11.ESSENTIALSCCDATAMODELFROMAGENERICPERSPECTIVE............................................................................47FIGURE12.EXAMPLEOFADATACOMPONENTASANINSTANTIATIONOFTHEESSENTIALSCCDATAMODEL.................................48FIGURE13.DATAVALUECHAIN..................................................................................................................................49FIGURE14.ASIMPLEEXAMPLEOFTHECONCEPTOFLINKEDDATA......................................................................................50FIGURE15.ANEXAMPLEOFASPECIFICARCHITECTUREOFASMARTCITYPROJECT..................................................................51FIGURE16.INTEGRATIONSTYLES.................................................................................................................................53FIGURE17.REFERENCEUSECASEPATTERNSFORINTEGRATIONANDINTEROPERABILITY...........................................................53FIGURE18.PIVOTALPOINTSOFINTEROPERABILITY..........................................................................................................54FIGURE19.ESPRESSOEXAMPLEOFANOPENURBANPLATFORM-SOLUTIONCONCEPTDIAGRAM.........................................55
Page 9
9 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
LISTOFTABLESTABLE1.USEOFREFERENCEARCHITECTUREFORVARIOUSSTAKEHOLDERS.................................................................19TABLE2.DESCRIPTIONOFOPENURBANPLATFORMCAPABILITYCATEGORIES.............................................................25TABLE3.DESCRIPTIONOFCAPABILITIESPERLAYER................................................................................................38TABLE5.DESIGNPATTERNSWITHINTHEREFERENCEARCHITECTURE.........................................................................41TABLE7.RECOMMENDEDARCHITECTURALARTEFACTSFORANOPENURBANPLATFORM............................................43TABLE6.DATAVALUECHAIN.............................................................................................................................49TABLE7.ACRONYMS........................................................................................................................................58TABLE8.REVISIONHISTORY...............................................................................................................................60TABLE9.DISSEMINATIONLEVEL.........................................................................................................................60
Page 10
10 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
1.INTRODUCTIONTheEuropeanInnovationPartnershiponSmartCitiesandCommunities(EIPSCC)isastakeholderdriveninitiativestimulatedandsupportedbytheEuropeanCommission.TheEIPSCChasdefinedkeypriorityareaswhichwillbeaddressedthroughsixActionClustersincluding“IntegratedInfrastructures&OpenData”.Ageneralobservationisthatopenurbanplatformsareapre-requisitetosupportfasttake-upofsmartsolutionsincitiestoallowmanystakeholdersofacitytoparticipateandfordifferentvendorsolutionstobeeasilyintegrated.ThishasstimulatedaMemorandumofUnderstandingandourgoalistogainbroaderindustry,cityandothersupport,andtomoveforwardasacommitmentwithintheEIP.ThemarketforcurrentUrbanPlatform(s)isfragmentedanduncertainonthedemand-sideandlackinginteroperabilityandcommonstandardsinthesupply-side.TheintentoftheReferenceArchitectureanditsbelongingDesignPrinciplesistoprovidecitiesandcommunitiesthatwishtoimplementSmartCity&Communitiesinitiativesatrulymissionandvendoragnosticapproachthatwillresultinanenhancedinteroperable,standards-basedarchitectureandimplementationwhichisspecifictoamissionwhentheirspecificcitycontextisapplied.Inaddition,thisReferenceArchitecturecanbeusedwithexistingarchitecturestoplanforimprovinginteroperabilitymaturityandfunctioningofanexpandingtechnologysolutionforsmartcityinitiatives.Thismissionandvendoragnosticapproachismeanttoprovidekeyelementsandconceptsneededtobeaddressedtomaketheseresultingsolutionarchitecturesinteroperable.AcommonthemeamongthedefinitionswithintheworldregardingthetermReferenceArchitectureisthattheprimarypurposeofsuchaReferenceArchitectureistoguideandconstraintheinstantiationsoflogicalandsolutionarchitectures.Inaddition,aReferenceArchitectureshould:
• Providecommonlanguageforthevariousstakeholders;• Provideconsistencyoftechnologyimplementationtosolveproblems;• SupportthevalidationofsolutionsagainstaprovenReferenceArchitecture;and• Encourageadherencetocommonstandards,specifications,andpatterns.
Ingeneral,aReferenceArchitectureisanauthoritativesourceofinformationaboutaspecificsubjectormissionareathatguidesandconstrainstheinstantiationsofmultiplearchitecturesandsolutions.TheReferenceArchitectureaspresentedhereprovidesthekeyelements,alignedtoseveralotherEUinitiativesandworldwidestandardsregardingReferenceArchitectures.ItwillatleastcontainagenericyetintegralapproachincludingBusiness,Infrastructure,Data,Applications/Services,Security,andPerformancedomains,towhichtheconceptsofinteroperabilityandstandardsareapplied.1.1TARGETAUDIENCEThisdocumenthasvarioustargetgroupsthatwilluseit.Itisnotbydefinitionthatallchaptersandelementsaredeeplyunderstoodbyallreadersandusers.Thetargetaudiencevaryfromthemayorofacity,thecitymanageranditspolicymakers(C-level,budgetholder)allthewaythruasolutionarchitectthatneedtoimplementpartsofanopenurbanplatformandthepurchasingdepartmentthatwanttotendersolutions.Alsovendors(hardware,softwareandserviceproviders/systemintegrators)canusethedocumenttounderstandiftheirsolutionswillorcanfittotheReferenceArchitecture.
Page 11
11 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
1.2PURPOSEThepurposeofthisworkistoprovideguidanceanddirectiontostakeholders(includingtheSmartCityandCommunitiesinitiatives)onthebetteruseofReferenceArchitecturesforguidingandconstrainingarchitecturedescriptions,developments,andusagesforcurrentandfuturecapabilities.TheapproachtakenwastoresearchandleverageReferenceArchitectureinformationandbestpracticestodevelopacommondefinitionforReferenceArchitectureanddescribetheelementsthatcomposeasolidmissionandvendoragnosticReferenceArchitecture.Thekeypointsmadeinthisdocumentare:
• ReferenceArchitectureisdefinedasanauthoritativesourceofinformationaboutaspecificsubjectareathatguidesandconstrainstheinstantiationsofmultiplearchitecturesandsolutions.ThisdefinitionisapplicabletoallofSmartCityandCommunitiesinitiatives.
• Project-specificArchitecturesmaybedevelopedbyvariousorganizationsfortheirownpurposesandintendeduses,butthisReferenceArchitecturemustcontainthevariouselementsdescribedinthisdocument.
• ThegoalsandobjectivesofReferenceArchitecturearenumerous.Theysolveaspecific(recurring)probleminaproblemspace;explaincontext,goals,purpose,andproblembeingsolvedincludingwhenandhowReferenceArchitectureshouldbeused;andprovideconcepts,elementsandtheirrelationshipsthatareusedtodirect/guideandconstraintheinstantiationofrepeatedconcretesolutionsandarchitectures.
ReferenceArchitecturesmayaddressdifferentlevelsofabstraction(fromthespecifictothegeneralized)andatdifferentlevelsofcoverage(frompatternstofullend-to-endcoverage).Weunderstandthatmanypeoplehavedifferentdefinitionsofthetermarchitecture.Sincethisisacontinuingjourneyamongstarchitects,wehavedecidedtousearathersimpleTOGAF-baseddistinction.ThisWorkstreamfocusesontheReferenceArchitectureanditsDesignPrinciples,basedonwhichSmartCitiesandCommunitiescancreatetheirownFocusAreastodetailfirsttheLogicalArchitecture,andafterthataspecificSolutionArchitecture.ItmustbeclearthatthisdocumentonlyprovidestheReferenceArchitectureandDesignPrinciples,anddoesNOTprovideanyothertypesofarchitecture.WewillprovidetheReferenceArchitectureinsuchamannerthatbasedonthisanimplementationortendercanbeexecuted.Everyusercanderiveproject-specific(logicaland/orsolution)architecturesfromthisReferenceArchitecture.1.3VALUEOFAREFERENCEARCHITECTURESowhatisthevalueofusingsuchreferencearchitectures,andwhyandwhenshouldyouemploythem?Firstofall,referencearchitecturesprovideaframeofreferencethathelpyoutogetanoverviewofaparticulardomainandtheyprovideastartingpointforspecificarchitectureefforts.Theyprovideeveryonewithbasicstructuressoyoudonothavetoreinventthewheel(whichoftenturnsouttobesquareanyway).Referencearchitecturesaremostvaluableforthoseaspectsandelementsofanorganizationonwhichyoudonotcompetewithothers.Asecondreasonforusingreferencearchitecturesisinteroperability.Inourincreasinglynetworkedworld,organizationsneedtoconnectandcooperatewithallmannerofotherparties.Thestandardsandbuildingblocksprovidedbyreferencearchitecturesfacilitatetheseconnections.Arelatedbenefitisthatusingstandardsimprovesflexibility,becauseitiseasiertoexchangebuildingblocks
Page 12
12 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
thatconnectviastandardizedinterfaces;viceversa,itismucheasiertodevelopstandardsifthebuildingblocksthemselvesarestandardized.Thisthenbringsustoathirdreasonforusingreferencearchitectures:mergers&acquisitionsandoutsourcing.Iftwopartiesspeakthesamelanguage,usethesamestandards,andrecognizethesameboundariesbetweenfunctions,processesand/orsystems,itwillbemucheasiertorecombinetheirelementsinnewways.Afourthreasonforusingreferencearchitecturesistofacilitatebenchmarkingwithinanindustry.Often,thedifferencesbetweencompaniesarenotinthedesignofe.g.theirbusinessprocesses,butintheirexecution.Usingreferencedesignsmakesitmucheasiertocomparethoseexecutionresults.Benchmarkingleadsustoafifthreasonwhyreferencearchitecturesareimportant:regulatorycompliance.Often,referencearchitecturesareprescribed(oratleaststronglyrecommended)byregulators.Accountingprinciples,practicesandprocesses,forexample,areincreasinglystandardizedandmandated.Thisleadstobusinessreportingstandards,evendowntothelevelofexchangestandardssuchasXBRL.1.4DOCUMENTSTRUCTURE/READINGGUIDANCEInchapter2wedescribetheContextandBackgroundoftheinitiativethatledtothisdocument.Inchapter3wedescribetheArchitecturalVisionWS2hasadopted.Inchapter4wedescribetheReferenceArchitecture,consistingofseveralinterrelatedparts:BusinessReferenceArchitecture(CapabilityMapandBusinessServices)andtheInformationSystemsReferenceArchitecture.AlsotheDesignPrinciplescanbefoundhere.
Page 13
13 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
2.CONTEXTANDBACKGROUNDBy2025300millionEUcitizensareservedbyplatformswithintheircitiesandinshort-termacceleratetheadoptionofOpenUrbanPlatformsthroughaneasy-to-implementtemplateapproach,andcross-sectorcollaboration1.OpenUrbanPlatformsformacorebuildingblockbywhichcitiesbettermanagethecurrentexplosioninvolumesofcitydataandmoreeasilysharethisdatabetweencityservicesinordertoimproveoutcomesforsociety.TheOpenUrbanPlatformInitiativecomprisesthreecoreelements:
1. Demand-Side–todefinecommonrequirements,andspeedadoption.Commonandalignedsetofrequirements,andmoreinnovativebusinessmodelsandacquisitionprocessestoacquireopenurbanplatforms.Typically,thedemand-sideisunderexposed;thechallengesofcities/communitiesarethebasisonwhichthesolutionshavetobemodelledafter.Also,thedemand-sideneedswaystogetandstayinvolvedinthestandard-settingprocess
2. Supply-Side–tobringtogetherEUIndustrytoadoptopensolutionsandtomobiliseindustryonapan-EUbasistocommittoareferencearchitectureforopenurbanplatformsthatservicesdemandsideneeds.Maximisestemplatecomponent-basedsolutionsthatenableaffordablestandardsbasedsolutionstobeputinplaceincities,therebyavoidingvendorlock-inandpromoteinteroperabilitybetweenthevariouscityservicesandservicesbetweencities.Solutionshavetobedevelopedbasedoncity’schallenges(demandside),insteadofforcingafitbetweenanexistingindustrysolution(that’sreadyformarket)andacity’sinfrastructural/ITproblems.
3. Standardization–raiseawarenessforinteroperabilityandtoformalizethecaptureofthecorecontentasinternationalstandards.Toestablisharobustbasistodevelopandproveamorecommonopenandsustainablebasisbywhichtheopenurbanplatformmarketisdeveloped–thisshouldincludestakeholderparticipationduringdevelopmentandreviewcycles.
Figure1.EIPSCCInitiatives
1https://eu-smartcities.eu/content/urban-platforms
Page 14
14 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
2.1SCOPEOFEIPSCCOPENURBANPLATFORMS
Figure2.ScopeofEIPSCCOpenUrbanPlatforms
Inourvision,SmartCitieshavekeycomponentsofinfrastructureandservices–environmental,emergencyresponse,trafficandenergymanagementtonameafew–integratedinsuchawaythatfeaturesandapplicationscaneasilybecombinedwithwhatevercapabilityexistedbefore.Achievingthatvisionrequiresmovingbeyondmanycurrentimplementationsinwhichthedegreeofintegrationofcoresubsystemswithinsmartcitiesisoftenlimitedbypatchworksoflegacyandfixedsolutionsconnectedbycustomintegrations,ifany.Therefore,wehavethewishtocreateanopen,referencableandcomposableSmartCity(Urban)Framework.Specifically,wedonotaimtocreateasingleormonolithicurbanplatform,sincethatwouldsuggestthatonesingleplatformshouldbethesolution.Rather,weexpectthatmultiplesystemswillariseandbeimplemented,basedonastandardwayofworkingwithcomponentsthatadheretoopenstandards,patternsandreferences,thattogethergiveshapetoanopenurbanplatform,whichisthereforemorealogicalthanatechnicalentity.By‘composable’weimplythatcontinuousintegrationandimprovementwillbeachievedthrougheasyadditionoffunctionasopposedtowholesalereplacementorretrofitting.Citiesintegratingeachnewcapabilityshouldbeabletosimplyacquireandaddittotheexistinginfrastructurewithaminimumoftailoringandreworkofexistingcomponentinterfaces.Thiswillresultinsynergeticeffects,with‘thewholewillbegreaterthanthesumofitsparts’.ConveningthisWS2workgroupwehavepursuedtoachieveconsensusonasmartcityorratheropenurbanplatformframeworkthatmeetsanumberofneeds.CitiesandentrepreneursgloballyandwithinEuropeseektoenableincrementallyadded“smarts”tovariousaspectsofcityliferegardlessofwhichcommunityofinterestthecomponentscomefrom.Andtheydonotwanttowaittodeploythesecapabilitiesinanticipationofthearrivalofsomekindof“grandscheme”or“totalsolution”.Adesirable(reference)architecturewoulddrawontheexistingworktominimizethebarrierstointegratingcriticalaswellasnewandnovelapplicationstothebenefitofcitizensandcitymanagers.TherecentsignificantlyincreasinginterestandprogressinSmartCitiesandurbanprogramswillprovidemanyinsightsandlessonslearned.However,mostcitiesareonlyatthebeginning,andsometimesevenbeforetherealbeginning.ManyteamsofimplementersandcitiesarepioneeringapplicationswithinEurope.TherearealsomanyconsortiaandstandardsorganizationsdevelopingarchitecturesofvariousscopesappropriateforSmartCityintegrationsorequivalents.Allofthesegroupswouldbenefitfromtheabilitytoworktogetherthroughacommonlanguage,frameworkandarchitecturalprinciples.
European Innovation Partnership on Smart Cities and Communities - Strategic Implementation Plan
Page 7 of 22
2 Problem analysis
The context that underpins this SIP, and calls for scale and accelerated action has been discussed. At present, European Member States, cities and communities throughout Europe, are taking different approaches to how they respond to the challenges of urban transformation. By itself this is not unexpected, however given the extensive commonalities that exist at a systemic level between cities, and the constant need for progress, there is scope for a more coordinated and complementary approach. This will: access the economies of scale that can deliver more affordable solutions; focus innovations from across Europe on the integration of the three areas; and help Europe to remain globally competitive.
The EIP is a stakeholder-driven initiative with the EC in a mediating / facilitating role, so that the principle of subsidiarity remains intact.
Given the scope and complexity of cities, the approach taken in preparing this Strategic Implementation Plan has been to consider three ‘vertical’ domains, and eight ‘horizontal’ enabling themes (see illustration). For the former, potential exists to improve outcomes through applying smart approaches that integrate across city systems, exploit existing assets, whilst also upgrading with new assets. For the latter, coordinated actions at a European Institution and Member State level can deliver the enabling environment within which cities, industry, and other stakeholders can achieve success, at scale, faster.
These eleven inter-dependent priority areas are considered to be the most important concerning Smart Cities and Communities, and the intersection with the areas of energy, transport and ICT.
Figure 3: Priority areas
Each priority area is discussed individually, against three main considerations: the context and challenges we are addressing; the drivers and desired state we seek; and what actions can help result in game-changing outcomes.
Page 15
15 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Aswellasindustryinterest,governmentshaveakeendesiretobenefitfromtheefficientintegrationof“Smart”intotheircities.Arecentreportpredictsthatby2017twentyoftheworld’slargestcountrieswillhaveinplaceprioritizednationalsmartcitypoliciesandonethirdofmediumandlargecitiesworldwidewillhavedevelopedasmartcityroadmap.Asharedsmartcitiesframeworkcansupportinformedpolicyanddecision-makingandpromotetheemergenceofavibrantglobalmarketforsmartcitytechnologies.Tomeettheneedsofallstakeholders,theworkinggroupisatechnology-andbusiness-model-neutralforumforcapturingaminimumsetofcommonalitythatcanbeadoptedtoachievethecomposablevisionofaSmartCity/OpenUrbanplatform.Thegoalistofindacommonintersectionofconsensusamongthestakeholdersaroundwhichallparticipantscanrally.Overthenextdecade,thewaywelive,workanduseenergy,transportationandothercityresourcesandserviceswillchangesignificantlythankstoarangeofinnovative‘SmartCity’solutions.ASmartCityintegratesphysical,digitalandhumansystemstodeliverasustainable,prosperousandinclusivefutureforitscitizens.Manyoftheseinnovativesolutionswillbebasedonsophisticatedinformationandcommunicationtechnologies.However,technologicalcomplexity,aswellasthecomplexityofthevarioussectorialservicesinvolvedwithinaSmartCity,requireasystemapproachtostandardization.SuchanapproachmustpromotethegreatestpossiblereuseofexistingopenstandardstoaccelerateSmartCitydeploymentandexploittheenormouspotentialderivingfromuseofdisparateinteroperabletechnologiesandfromre-useofinteroperableapplicationsandservicesamongcities.AsWS2wefocusonthethreemainapplicationdomainsorareasthatarescopedwithinourassignment:
1. SustainableUrbanMobility2. SustainableDistricts&BuiltEnvironment3. IntegratedInfrastructure&Processes
Althoughitmightbetemptingtobroadenthescope,sinceaReferenceArchitectureshouldbeabletocaterfor,thisisdeliberatelynotinscopeofWS2.Itwouldcreatelargercomplexity,besidesthefactthatwithintheentireEIPSCCnootherworkstreamstakeotherpriorityareasintoscope.2.2ONECOMMONFRAMEWORKFORARCHITECTUREWS2iscomplementarytotheresultsoftheotherEIP-SCCworkstreams.AcloselinkwillbeestablishedwiththeEspresso-OpenGeospatialConsortiumOGCEuropeGroup,sincemanyoverlapscanbeidentified.Espressowilldevelopa“ConceptualSmartCityInformationFramework”.WS2hasadoptedthegloballyacceptedandmostwidelyusedTOGAFFrameworkasstandardArchitecturalFramework_.TheuseoftheTOGAFarchitecturalframeworkresultsinarchitecturesthatareconsistent,respondtostakeholdersneeds,adoptsandemploysbestpractice,andgivestheappropriateconsiderationtothecurrentandfuturerequirementsofagivenenterprise.Therefore,TOGAFprovidesbothtoolsandmethodsforthe“acceptance,production,use,andmaintenanceofanenterprisearchitecture”(TOGAF9.1).TOGAFusestheArchitectureDevelopmentMethod(ADM)asastep-by-stepapproachedtodevelopingenterprisearchitecture.Itdescribeshowtocreateanorganizationorcontextspecificenterprisearchitecturethataddressasetofbusinessrequirementsandrespondstostakeholderconcerns.
Page 16
16 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Figure3.TOGAFFramework2
WithregardstoaReferenceArchitectureathandhere,withinTOGAFWS2focusesontheelementsA(ArchitectureVision),B(BusinessArchitecture)andC(InformationSystemsArchitecture),withsomefirsthighleveldescriptionsofelementD(TechnologyArchitecture).ItmustbeclearthatwedonotdeliveraLogicalnorSolutionArchitecturesinceforeveryinitiativethiswillvary.Besides,theReferenceArchitectureestablishedhereistrulyprojectandvendoragnostic.ToscopetheWS2efforts,weusetheTOGAFEnterpriseContinuum,whichshowstheentirestackofvarioustypesofarchitecturesthatinterrelatetodefineandimplementspecificsolutions.WS2focusesontheArchitectureContinuum–GenericArchitecturespartandtheArchitecturalContextandRequirements.Weadoptseveralspecificarchitecturesgloballyavailableandadopted,andcreateagenericarchitecture,thatservesforcitiesandcommunitiesasareferenceandcanbeadaptedforspecificarchitectures.Italsoguidesandsupportgenericandspecificsolutionsthatcanbedeployedinaspecificsituation.
2 Source:TheOpenGroup
Page 17
17 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Figure4.WS2ScopeplottedonTOGAFEnterpriseContinuum
WS2recognizesthelargevarietyofuseandperspectivesonarchitecture.Todevelopthereferencearchitectureforopenurbanplatforms,WS2willthereforeadheretoTOGAFasagloballyusedandadoptedframeworkthatstandardizesvariousviewpointsandperspectives.Todevelopspecificarchitecturesandsolutionsforspecificcitiesorcommunities,werecommendtheuseofthesameframework.
Page 18
18 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
3.ARCHITECTUREVISIONThischapterisdedicatedtothevisiononarchitecturethatisrelevantfortheinitiative.First,weobservethatalthoughwehaveaclearvisionon(thefutureof)smartcitesandtheneedforopenurbanplatforms,thereareundoubtedlymanynewandunforeseeninnovationsandinitiativesthatwillariseduringthenextdecade(s).Therefore,weneedtocomeupwithanarchitecturethatissufficientlyflexibletoadoptnewinitiativesandsolutions.Asstatedbefore,thisWorkStreamwithinEIP-SCCisfocusedondeliveringaReferenceArchitectureanditsbelongingDesignPrinciples.Inordertodoso,wedefineaReferenceArchitectureasfollows3:
“Areferencearchitecturemodelstheabstractarchitecturalelementsinthedomainofinterestindependentofthetechnologies,protocols,andproductsthatareusedtoimplementaspecificsolutionforthedomain.”
3.1REFERENCEARCHITECTURESTAKEHOLDERVALUEAlthoughacommondefinitionofReferenceArchitecturehasbeenset,theuseofsuchaReferenceModelvariesperstakeholder.AcitymanagerwillusesuchamodelinadifferentmannerthantheITprocurementofficerorasoftwaredeveloper.ThissectionofthedocumentisdedicatedthevariousgroupofstakeholdersthatwillbenefitfromtheapplicationoftheReferenceArchitectureandDesignPrinciples.Thesebenefitsstemfromvariousdirections:societalandsustainableperspective,businessperspectiveandamoretechnicalperspective.Stakeholder4 UseofReferenceArchitectureCityLeaders UnderstandingtheconceptofanOpenUrbanPlatformandthebasic
componentsandrelatedprinciplesofsuchaPlatformPoliticalAdvisors UnderstandingtheconceptofanOpenUrbanPlatformandthebasic
componentsandrelatedprinciplesofsuchaPlatform,andtranslatingthisintopracticalpoliciesandguidelines
CityManagement UnderstandingtheconceptofanOpenUrbanPlatformandthebasiccomponentsandrelatedprinciplesofsuchaPlatform,anddecideonprioritiesandresourcesrelatedtothis
Procurement TheentireReferenceArchitectureandDesignPrinciplescanserveasafull-bodiedandcomprehensivesetforselectingandtendering(partsof)theUrbanPlatforminspecificsituations
ITLeads Understandingthe(basicprinciplesofthe)ReferenceArchitectureandputaportfoliotogetherwiththebusinesstoensurethattheentireITstackis
3Sources:OASIS-www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm,andTOGAF-http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html4WherewestateCitythiscanalsobeaCommunity
Page 19
19 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Stakeholder4 UseofReferenceArchitecturedirectedinthedirectionoftheReferenceArchitecture.Italsoservesasacommon(shared)communicationsmannertomakeiteasytocomparesolutionsanditsarchitectures
ITDevelopersandImplementers/Integrators
Understandingthe(basisprinciplesofthe)ReferenceArchitectureandputaportfoliotogetherwiththebusinesstoensurethattheentireITstackisdirectedinthedirectionoftheReferenceArchitecture.Italsoservesasacommon(shared)communicationsmannertomakeiteasytocomparesolutionsanditsarchitectures.ItservesasaLeadingGuidetoensurethatcomponentsofanOpenUrbanPlatformwillworktogetherwithotherpartswithouthavingtocreatespecificsoftware,interfacesorAPIs.Thefocusisonproductivityandtools,anddoesn'tincludethingssuchasactuallivedataandconnectionswithconsumers.
Vendors/marketplace Understandinghowtheirsolutionsandsuitesarefitting(ornot)withtheReferenceArchitectureanditsDesignPrinciples,inordertoensurethattheirsolutionswillco-existinacost-effectivemannerwithothersolutionsinanOpenUrbanPlatform
Users/citizens Understandhowcitiesdeliversolutionsinacosteffectiveandefficientmannerwhenspendingcitizens’money.Theyfocusonallthewaysinwhichtheuserinteractswiththesystem,notseeinganydetailssuchasapplications.
Table1.UseofReferenceArchitectureforvariousstakeholders
3.2FOUNDATIONALPRINCIPLESANDASSUMPTIONSOurvisionistohaveaReferenceArchitecturethatistrulymission,projectandvendoragnostic.Itthereforemaynotcontainanyformoftechnicalitiesnorsolutionelements,normayitbeprescriptiveorexcludingcertainsolutions.Itmustbeabletoactasarealreferenceforcitiesandcommunities,andotherrelevantstakeholders,thathavethewishtorealizeacomprehensivesolution,oronlypartofit.WhenanalyzingseveralotherReferenceArchitecturesandtakinginputsfromEIP-SCCdemand-sideandstandardsworkstreamsintoconsideration,WS2drawstheconclusionthatseveralcommondenominatorsarepresentamongthosearchitectures.ThesecanbeseenasfoundationalprinciplesandassumptionswhichformthebasisfortheReferenceArchitecturepresentedinthisdocument:
• Alayeredapproachtowardsarchitectureisdesirable,toensureacommonandvaluabledecompositionoflogicalclusters,withinandbetweenstandardizationmusttakeplace
• Capabilitiesarethecenterelementofthearchitecturestoensurethatacommongroundiseasytobefound
• Thereferencearchitectureshouldallowandcertainlynothinderincremental,iterativeevolutionaryapproachesforimplementationofopenurbanplatforms,typicallystartingbyfocusingonexistingopportunities/painpointsandthenincrementallyfurtherexpandingtheplatformovertime.
• Openurbanplatformsshouldbebasedasmuchaspossibleonopenstandards,preferablybasedonlarge-scaledeployments.Especially,betweenthevariouslayersinanurbanplatform,standardsarepromotedtosupportflexibilityandprevente.g.vendorlock-in.
• Thereferencearchitectureshouldenableavarietyofopenurbanplatforms.Ingeneral,thereferencearchitecturemustbeagnostictotechnology,marketstructure,implementationmethod,vendorandproducts.
• Modularity:thereferencearchitectureshouldenablecitiestouseanddeployvarious(combinations)ofmodulesintheopenurbanplatform,notrequiringacomplete‘bigbang’
Page 20
20 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
implementationofanopenurbanplatform.• Thereferencearchitectureshouldsupportre-useofexistingprovenarchitectures,whichare
typicallyaimedatspecificlayers(e.g.IoT,communications,datamanagementetc)andmoredetailedormoretechnical.Thereferencearchitectureforopenurbanplatformshouldbeconsideredasacommon‘umbrella’thatallowsthestructuredpositioningofexistingarchitecturesandassociatedimplementedsolutions.
• Thereferencearchitecturedescribedinthisdocumenthastoremainvalidforaslongaspossible,eveniftechnologyandstandardschange–makingthereferencearchitectureasmuchaspossiblefutureproof.
• Any-Infrastructureapproach(OnPremise,SaaS,PaaS,IaaS)withthesamereferencemustbepossible(i.e.,theReferenceArchitectureisagnostictoinfrastructuredeploymentscenarios)
• Applicationdesignanddatamodelingattheleveloflogicalandsolutionarchitecture,isnotpartoftheReferenceArchitecture,butpartofcityspecificinitiatives,withthisreferencearchitectureasastartingpointand‘commonumbrella’.
• Thereferencearchitecturecouldprovideabasisforcompliancecertificationofopenurbanplatformsolutions,products,services,orpartsthereof(notpartofcurrentEIP-SCCscope)
• ThecurrentworkisfocusedonthethreepriorityareasasdefinedinEIPSCC,promotingthatalongthosethreeareasnoconstraintsexistswhen‘borders’arecrossed.Inprinciple,alsootherpriorityareasmightberelevanttobesupported‘withoutborders’byurbanplatforms,butsuchareasareoutsidethescopeofthecurrentwork.
Withthislistoffoundationalprinciplesandassumptions,wehaveformulatedthefollowingarchitecturalvisionstatement:Keyelementsofourvision:
a. Capabilitybasedb. Layeredc. Standardsbasedd. Marketandvendoragnostice. Noprescriptionofsolutionsnortechnologiesf. Modularg. Incrementallyachievable
WS2explicitlyacknowledgingthatalreadyvariousverysoundanduseablearchitectureshavebeendeliveredglobally,whicharewidelyadopted,andwhichadheretothefoundationalassumptionsasdescribedabove.Weexplicitlydonotwanttoreplaceanyexistingreferencearchitecturebutratherwanttocomplementexistingworkbyprovidingareferencearchitecturethatisfocusedonopenurbanplatforms,which‘standsontheshoulders’ofexisting,typicallymorespecificormoregeneric/non-domainspecific(reference)architectures.RegardingtheArchitectureGovernance,WS2doesnotmakeanystatements,sinceeveryproject,city,initiativewillfollowitsowngovernance.However,WS2promotesasoundgovernance,especiallywithregardstotheuseoftheestablishedReferenceArchitecture&DesignPrinciples.
Figure5.ArchitectureVisionEIPSCCOpenUrbanPlatformsWS2ReferenceArchitecture&DesignPrinciples
Page 21
21 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
3.3LINKSWITHOTHERINITIATIVESEIP-SCChasthreeinterdependentinitiativesinsupportofthedevelopmentandspreadofopenurbanplatformsplatforms,asdescribedinchapter2:
• Firstly,ademand-side(city)initiativethatwilldevelopacity-needs-ledsetofcommonrequirements;plus,templatesandtoolstohelpcitiesengagefastandconfidently.
• Secondly,aSupply-Sideinitiative–themainsubjectofthisdocument–todevelopanreferencearchitectureforopenurbanplatforms.
• Thirdly,aworkstreamisdedicatedtoidentifyingrelevantstandardsandrelatingthemtoelementsinthefirstandsecondworkstreams.
In addition, a close cooperationexistswith the Espressoproject,started in early 2016,whichwillalso capture the results of the above and will help to sustain momentum and to promoteconsistencybetweeninitiatives.Morespecifically,theoutputofWS3(Standards&Standardization)isalignedwithESPRESSO’sD2.3(DefinitionofaConceptuAlStandardS InterOPErabilityfrAmework(CASSIOPEiA)forSmartCity)andthisWS2document,toensurethatacomprehensiveandalignedperspectiveispresentedtousersoftheentireset.TheWS2ReferenceArchitectureandEspresso’sarchitecturalproductsaredesignedtobemutuallycompatible.ESPRESSO’sdeliverablesD2.4(crossSDO GAP and SWOP analysis) will bring together the standards described in D2.3 with thisdocument–meaningthatstandardswillbeassignedtothevariouslayersofthearchitecture.
Figure6.Roadmapandinterdependencieswithotherinitiativesandworkstreams
Management Team
Esp
ress
oSupply
Dem
and
Cityrequirement
specifications
WS1 List ofStandards
UP StandardsInventory (tbc)
Clear statement of need; and meansby which cities define common setof needs for the market
Opinion
Fact
Need to define roleof Industry & Espressofor this - clearly a joint activity
SC Info; & InterOpFrameworks
Tier 1: LeadershipGuide (v01)
Tier 2: MgmtFramework (v01)
WS2: Ver01 RefArchitecture
Map Standards toarchitecture
Short key issue guide for politicaland executive engagement
Organising framework tosupport cross-silo outcomes
“A” for Ver 01 with Supply
Ver 02 with Espresso; SDOs; Supply
Tier 1-2-3 portfolioof guidance materials
Espresso pull materials throughtowards long-term capture in SDOmaterials
Related Deliverables· UP Toolbox· ‘Which Guide’ for UP· Procurement Template· ...
Page 22
22 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
4.REFERENCEARCHITECTUREThemainpartofthisdocumentisdedicatedtothedescriptionoftheReferenceArchitectureandDesignPrinciples.Todothis,wehaveselectedanumberofarchitecturalproductsthatfitourgoalsandneedsinthecurrentcontext.First,weintroduceaso-calledcapabilitymap,whichinTOGAFtermsisconsideredtobepartofthe‘businessarchitecture’,implyingthatthecapabilitymapismoreaboutspecifyingwhatisneededfromaSCCperspective,andnotfromatechnologicalperspective.Thecapabilitymapisseenhereasthecoreoftheopenurbanplatformarchitecture–thecommonframeworkthatprovidesasharedvision,structureandterminologyforallrelevantstakeholders.Afterdescribingthecapabilitymap,weproceedbyidentifyinganumberofdesignprinciples(andpatterns)andprovideinputformorecity-specificarchitecturewhich-followingTOGAF-wecall‘informationsystemsarchitecture’,withspecialfocusonunderlyingdataandapplicationarchitecture.Thiswillbeexplainedinmoredetailinlatersubsections.4.1INTRODUCTIONAllcitiesareunique,yetallsharesimilarchallenges,includingthedesign,implementationandrunningoftheiropenurbanplatform.Althougheachcityorcommunitymayhaveitsowninstanceofitsownopenurbanplatform,tailoredtolocalneeds,akeyandbasicassumptioninourarchitecturevisionisthatmostopenurbanplatformsharealotofcommonalities.Thesecommonalitiesareimportant,astheyprovidethefollowingpotentialadvantages:
• Newopenurbanplatformsmayreuseexisting(partsof)urbanplatforms,thusimprovingspeedandefficiencyintheirdevelopment.Likewise,openurbanplatformsmaybepurchasedordevelopedandthensharedbyagroupof(smaller)citiesandcommunities,againimprovingspeedandefficiency,andmakingtheuseofanopenurbanplatformmorefeasibleforsmallercitiesandcommunities.
• Openurbanplatformsthataresimilarindifferentcities&communities,provide(more)consistencytowardscitizensandotherstakeholdersintermsofhowtheirdataishandled,howprivacyandsecurityaremanaged,howtransparencyisprovidedabout(automated)decisionmaking,andsoon,thussupportingthemobilityandfreemovementofstakeholders.
• Themarketforopenurbanplatformsbecomeslargerandmoreinterestingforsuppliersofurbanplatformproductsandvalueaddingservices(NBopenurbanplatformsdonotnecessarilycorrespondtoasingleproduct,butmaybecomposedofseveraldifferentproducts).Insteadofhavingtodevelopaunique,tailormadeurbanplatformforeachandeverycity,suppliersmaydevelopopenurbanplatformsasamorestandardizedproduct,whichcanbepurchasedbymultiplecitiesandcommunities.Thismay,inturn,providemorecompetitionandmaylowerthecostsofopenurbanplatforms.
However,toturntheseandotherpotentialadvantagesintoreality,aprerequisiteistohaveaunderstandingandvocabularyor‘referenceframework’thatiscommontoallopenurbanplatformrelatedstakeholders,includingurbanplatformowners,architects,developers,managersandothers(seealsosection3.1)Also,asstatedearlierinourarchitecturalvision,thiscommonreferenceframeworkneedstobeagnosticwithrespecttocity,community,technology,productandsupplier.Inourvision,thereferenceframeworkshouldbeusableforallopenurbanplatformsascharacterizedhere,nomatterhowitisimplementedandbywhom.
Page 23
23 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Anotherimportantaspectofthearchitecturalvisionhereisthatalthoughwerefertoasinglecommonreferenceframework,thisdoesnotnecessarilyimplythatanyopenurbanplatformshouldbeasingleimplementation,asinglephysicalsystem,orthatitshouldbeasinglevendorthatissupplyingacity’surbanplatform.Infact,itismorelikelythatanopenurbanplatformrealizationactuallyconsistsofmultiplesystems,existingornew,possiblyfrommultiplesuppliersorfrommultiplecommunaldepartments,onlyatlogicallevelassembledintoanurbanplatform.Thesinglecommonframeworkishoweverasharedlogical‘umbrella’,thatmakesclearwhichsystemsandsolutionsarefulfillingwhichpartsoftheurbanplatform.Withtheaboveinmind,inthischapterweprovideacommonreferenceframework,inwhatiscalleda‘capabilitymap’forurbanplatformsCHARACTERIZATIONOFANOPENURBANPLATFORMAnOpenUrbanPlatformischaracterizedhereasfollows:
• Theimplementedrealizationofalogicalarchitecture/content/designthatbringstogether(integrates)dataflowswithinandacrosscitysystems;
• exploitingmoderntechnologies(sensors,cloudservices,mobiledevices,analytics,socialmediaetc.);
• providingthebuildingblocksthatenablecitiestorapidlyshiftfromfragmentedoperationstoincludepredictiveeffectiveoperations,andnovelwaysofengagingandservingcitystakeholders;
• inordertotransform,inawaythatistangibleandmeasurable,outcomesatlocallevel(e.g.increaseenergyefficiency,reducetrafficcongestionandemissions,create(digital)innovationecosystems).
4.2OPENURBANPLATFORMCAPABILITYMAPCAPABILITIESEXPLAINEDCapabilitiesrepresentwhatacityorcommunitydoestoexecuteitsmissionanddeliverservicesthatmeettheneedsofcitizensandotherstakeholders.Acapabilityisanabstractrepresentationofwhatisneededtoproduceanoutcomebyanorganizationorotherhumancollectives–alongwithgoalsandmetricsforthatoutcome.Capabilitiescanactuallybeimplementedbylinkingthemtorequiredpeople,processes,technology,informationandassets.Alternatively,capabilitiescanbelinkedtooneormore‘services’thattogether‘realize’acapability.SuchservicesmayincludeITapplicationservices,technicalservices,externalservices,andsoon.Capabilitiescanbestructuredandgroupedin‘capabilitymaps’.Capabilitymapscanbeusedasatoolforplanningandassessment:whichcapabilitiesarealreadyinplace;whichonesneedfurtherdevelopmentorarelacking?Capabilitieshavebecomeawidelyusedtooltohelpunderstandtheimplicationsofbusinessdrivers,clarifypriorities,andplaninvestments.Forexample,acommoncapabilityisfinancialmanagement—allaspectsofmanagingacity'scashflow,financialassetmanagement,andreporting.Financialmanagementisaconceptualcapability,andtheactualimplementationusespeople,processes,information,andtechnologytoprovidetherequiredoutput—inthiscase,effectivemanagementofacity'sfinances.Moreover,financialmanagementmaybeimplementeddifferentlyfromcitytocityorevenwithindifferentpartsofthesamecity;differentcitiesorareaswithinacitymightoutsourcecertainfunctionsorusedifferenttechnology.FromtheaboveitshouldfollowthatCapabilitiesdonotcorresponddirectlywithsingleorganizationalprocesses.Nordotheyarenecessarilyequivalenttosingletechnologicalorphysical
Page 24
24 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
solutions.Instead,capabilitiesareamoreabstractwayofdescribingwhatacityorcommunityshouldbeabletodo,whileremainingagnostictohowexactlythecapabilityisimplemented.Thisallowsforacomparisonbetweencitiesthatstressessimilaritiesandallowsforeasierreuse,sharing,consistencyandproductizing.Capabilitiescanbelinked(withmany-to-manyrelationships)toorganizationalprocesses,services,people,departmentsandsoon,includingITapplications(ormodulesthereof).Thelattercanbedoneinaso-called‘Application/CapabilityMatrix’-seesection4.4CAPABILITYCATEGORIESAllcapabilitiesthatarerelevantinthecontextofanUrbanPlatformhavebeengroupedinanumberofcategories.Capabilitieswithincategoriesaremorelikelytobeinterdependentandtightlycoupledthencapabilitiesfromdifferentcategories.Typically,interactionbetweendifferentcapabilitycategoriesismorestandardized,makingonecategoryagnostictothewayothercapabilitiesarefulfilledorimplemented.Putdifferently,categoriesarepreferablymorelikeblackboxestoeachother,requiringinputandprovidingoutput,withouttheneedtoknoworhavingadependencyonthespecificimplementation.Incaseofchangesorinnovationsinonecategory,thisallowsforlessimpactonothercategoriesandhenceformoreflexibility.WithinthescopeofscopeofEIPSCCUrbanPlatforms,10capabilitycategorieshavebeendefined:CategoryNo
CapabilityCategoryName
CategoryDescription
0 FieldEquipment/Devicecapabilities
Capabilitiesthatenabletheexternalenvironment(fieldequipment,devices,IoT)tobemeasuredandcontrolledfroma'backoffice'(centralordecentrallocation).
1 Communications,Network&Transportcapabilities
Capabilitiesthatenabletheexchangeofdata(includingeventsandcommands)betweenapplicationsanddevicesandfieldequipment,andcapabilitiesthatenableandsupportthedatacommunicationbetweentheexternalenvironmentandthebackoffice.Itincludespositioningcapabilitiesthatcomprisesgeodetic,coordinationandvectorialdata.ThisalsoincludesM2Mcapabilities.
2 DeviceAssetManagement&OperationalServicescapabilities
Capabilitiesthatenablethedeliveryandassuranceoftheassetssupportingthedevicecommunicationsandintegration
3 DataManagement&Analyticscapabilities
Capabilitiesthatenabletheuseofdatabyapplications.Itwillincludecoredatamanagementandlifecycle(e.g.ingest,assure)relatedcapabilities,aswellascapabilitiestoanalyze,shareandpublish(open)data
4 IntegrationandOrchestrationcapabilities
Capabilitiestomanageandorchestrateprocessesandservicesinsupportofsystemandhumanactorinteraction.
5 GenericCity&Communitycapabilities
Capabilitiesthatenablethedeploymentofgeneric(non-cityorcommunityspecific)capabilities.
6 SpecificCity&Communitycapabilities
Capabilitiesthatenablethedeploymentofspecificcity/communitycapabilities,withthreemainstreams:SustainableUrbanMobility,SustainableDistrict&BuiltEnvironment,andIntegratedInfrastructure&Processes
7 Stakeholder Capabilitiesthatenablecitiesandcommunitiestoengageand
Page 25
25 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
CategoryNo
CapabilityCategoryName
CategoryDescription
Engagement&Collaborationcapabilities
collaboratewithalargevarietyofstakeholdersandtomanagethestrategicgoalsagendaandroadmap
8 Privacy&Securitycapabilities
CapabilitiesregardingintegralPrivacyandSecurityappliesacrossphysicalsitesandassets,devices,networks,data,applicationandpeople.Comparedtophysicalsecurity,cybersecurityisaimedatprotectingconfidentiality,availabilityandintegrityinthedigitalcontext,byapplyingamyriadoftoolsandmeasures,includingidentitymanagement,authenticationand(bothfunctionalanddataoriented)authorization,intruderdetectionandauditing.
9 CommonServicescapabilities
CapabilitiesthatsupportotherCapabilitiesregardlessofthelayerinwhichtheCapabilityisfound;thesearemoregeneric(IT)capabilities,notprogramormissionspecific.
Table2.DescriptionofOpenUrbanPlatformCapabilityCategoriesCAPABILITYMAPWhentranslatedintoa‘capabilitymap’,categoriescanbeorderedtorevealtheirgeneralinterdependencies(meaningthatonecategorycanonlyexistiftheotheralsoexists,onerelyingontheoutcomefromtheother,directlyorindirectly).E.g.category0providesafoundationforcategory1,category1for2,andsoon.However,pleasenotthatthisdoesnotimplythatcategoriesmayonlyinteractwithdirectlyadjacentcategories.Althoughthelatterismorelikely,itisalsopossiblethatdirectinteractionexistsbetweenmore‘remote’categories.Inadd\dition,themaprevealsthatcategories8and9haveagenericnature,interactingwithallothercategoriesinanequallylikelyway.
Figure7.OverallEIPSCCOpenUrbanPlatformCapabilityMap–overalllevel
Page 26
26 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
CAPABILITIESPERCATEGORYForeachcategoryasetofcapabilitieshasbeenidentified.Thesearepresentedinthepicturebelow.Theirdescriptioncanbefoundinthefollowingtable.
Figure8.EIPSCCOpenUrbanPlatformCapabilityMap–categorylevel
Page 27
27 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Category Nr Capability Description0 0.1 Sensoring&Measuring Senseschangesinconsumptionorproductionof
acommodity,instrumentationandenvironmentalfactorsandrecordstheseasinstantaneousvalues
0.2 DataCapturingandRecording
Storingofthevalues,measuredbythesensorsinthedevice,inregistersandothernon-volatilememorystructures
0.3 EventGenerationandRecording
Sensedchangesaredirectlycapturedaseventdataorvalues/dataaretranslatedtoeventsbasedonrules(e.g.thresholds)
0.4 RemoteAccessibility Communicationchannelsareopened,maintainedandclosed,overvariouscommunicationmedia,todeviceswhichareremotefromthecurrentdeviceeitheronthecommunicationsnetworkorontheHAN
0.5 LocalAccessibility Accessisprovidedlocallytodatastoredonthedeviceeitherviathelocaldisplayonthedeviceorthroughlocalserialoropticalportsonthedevicewhichallowalocalcommunicationssessiontobeestablished
0.6 LocalIntegration Describeshowotherdevices(In-HomeDevices,sub-meters,HomeManagementSystems,ControllableDevicesetc.)areupdated,read,controlled,upgradedetc.
0.7 CustomerMessaging Describeshowtext,tariff,priceandcontrolmessagesaredeliveredbythedevicetootherdeviceswithinthehomeordisplayedlocallyonthedevice
0.8 LocalControl Anactuator(controller)isabletochangethingsintheenvironment,e.g.connect/disconnectpowerontheconnection,loadlimitataconnection,controlsmartdeviceswithinthehomeanditsdirectenvironmentetc.
0.9 DeviceConfiguration Capabilitiesrequiredtomaintainthedeviceinadesiredstate(firmwareupgrade,re-configuration,clocksynchronizationetc.)
0.10 SecuritySupport Localdevicecapabilitiesrequiredtosupportimplementationofasecureend-to-endinfrastructure-thephysicaldevicemustprovidesecurityserviceswhichareusedtoimplementsecurecommunicationswithotherdevicesandsecurelocalstorageofdata
0.11 TimeKeeping Devicecapabilitiesrequiredtoensurethataccuratelocaltimeismaintained(criticalfortime-stampingofeventsanddata)
1 1.1 NetworkNodeAssetManagement
Managementofthefulllifecycleofcard/chipwherecommunicationstechnologyisdeployedinthedevice.Thisincludesthelogisticsupportofknowingthedevicemappingwiththe
Page 28
28 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Category Nr Capability Descriptioncard/chip.provisioningofthecard/chip,switchingthestateofthecard/chipandmaintainitsprofilethroughoutitslifeinthedevice
1.2 TelecommunicationsNetworkNodeConfiguration
Thedesignandconfigurationofthestructureofatelecommunicationnetworksothatdatacanbeexchangedbetweenthelocalcommunicationnetworkandtheindustry'scommunicationnetwork.Itincludestheabilitytooptimizethedesignovertimewhenthenetworkisinoperationtomeetthenecessaryperformanceandresiliencetargets
1.3 LocalNetworkManagement Thenetworkcontrol,operationandmonitoringofdevicesinthecustomerhomeorotherrelatedpremisessothatthesedevicescancommunicatesecurelywithoneanotherlocallywithinthepremises.Typically,thiswillinvolveacommoncommunicationprotocolsatphysical,networkandapplicationlayersoperatinginspecializedcommunicationdevicessuchascommunicationhub,bridgingdevice,gateway,repeatersaswellasthedevices
1.4 TelecommunicationsNetworkManagement
Theprovisioningofconnectivitybetweenthedevicesandtheindustry'sterminalsystems.Thecapabilitywillallowtelecommunicationnetworktobemonitoredinflight,ensuredesirednetworkperformanceisachievedandthatallincidentsarehandledinatimelymanner.Itwillalsoincludeschedulingofmessaginginviewofprioritybymessagetype
1.5 NetworkSecurity Thenetworkwillbesecuredattransportprotocollevelandattheoperationofthenetworkadministrationleveltoensurethatconnectivityismaintainedsecurelyatalltime
1.6 DataCommunicationManagement
Enablesa(two-way)datacommunicationbetweenapplicationsanddevicesviadatacommunicationsprotocols
1.7 DeviceProvisioning Provisioningofthedevicewhileactiveonthenetwork
1.8 DeviceConnectionManagement
Connectingdevicestothenetwork
1.9 DeviceandEventData(Edge)Processing
Collectdatafromdevices,time-synchronizedatabetweensensors/devices,transferdatatodatamanagementlayerand/or(pre-process)dataatorneardevice(alsoknownas‘edge’processing),e.g.tofilter,aggregateoridentify(simple)eventslocally,beforetransfer.
1.10 DeviceDataandEventStorageandDistribution
Temporarilystoring(raw)deviceandeventdatapreandpostprocessing(stagingareabeforesynchronizationwithupperlayer)
Page 29
29 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Category Nr Capability Description 1.11 Configuration
SynchronizationGettingtheneededmasterdataforthedeviceIntegrationfromtheupperlayer(s)andpossiblyfromthelowerlayer(s),includingtheinfrastructureitself
1.12 MessageandCommandSynchronization
Acceptingandforwardingthecommandfromtheupperlayers,managingthecommandstatusincludingqueuing
1.13 DataCommunication,Protection&Security
Securesthedatacommunicationoverthenetwork(e.g.viaencryption)
1.14 PositioningSynchronization Activesynchronizationofthepositionofacertaindeviceandthemanneritcanbecommunicatedwith
2. 2.1 DeviceRegistrationandConfiguration
RegistrationofthestaticpropertiesoftheassetsinthedeviceInfrastructureandtheabilitytoproperlyconfigurethemforusage
2.2 OperationalStatusMonitoring
RegistrationofthedynamicpropertiesoftheassetsinthedeviceInfrastructure
2.3 Error&AlarmsDiagnostics Handlingerrormessages,incidents,complaintsandoutagerelatedcases
2.4 DeviceServiceLevelManagement&Reporting
Monitoringandreportingondevicerelatedservicelevels
2.5 DeviceDataUnification&Validation
Unificationandvalidationofdatafromsingleormultiplesensorsfromoneormultipledevices,or‘sensorfusion’,beforefurtherdataprocessinginupperlayers.Thisincludesvalidation,uncertaintyreductionand(re)calibrationofsensorreadingsandactuatorprecisionandaccuracy.
2.6 Message&CommandHandling
Definingandmonitoringthemessagesandcommands,includingcommandlikeconnect/disconnect,powerlimiting/modulation,dynamictariff/ToUprogrammingandothercontrolevents
3. 3.1 DataIngestion Retrieve/receiveandtransferdatafromdatasourcesforfurtherprocessing,possiblywithintermediatedatastorageorstaging.Datasourcesmaybehighlydiverseintermsoflocations,formats,interfaces,protocols,standardsetc.
3.2 DataVirtualization Makingdataavailablefordataprocessinginasystem,withouttheneedofactuallystoringthatdatainthesamesystem.Rather,thedataisstoredinanothersystem,thatisenabledforvirtualdataaccess.
3.3 Non-timeseriesDataIntegration&Transformation
Integrateand–ifneeded-transformandharmonizedatafromoneormorenon-timeseriesdatasources(e.g.administrative/transactional,document,image,video,socialmedia,geographical,master&referencedata).Ofteninbatcheswithe.g.daily
Page 30
30 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Category Nr Capability Descriptionfrequency.
3.4 Time-seriesDataIntegration&Transformation
Integrateand–ifneeded-transform,harmonizeandtime-synchronizedatafromoneormoretimeseriesdatasourcesor‘streamingdatasources’,typicallydevice,sensorand(raw)eventdataaboutinfrastructure,weather,trafficetc.Oftencontinuous,in(near)real-time.
3.5. DataFusion Using(time-seriesornon-timeseries)dataintegrationtocombinedatafromdifferentdatasources,representingthesameobjectoractor,thusenablingmorecompleteviewsandinsights.
3.6 DataAggregation Summarizingdatabygroupingdataentitiesinhigherordercategories,and/orbycalculatingsums,averages,maximalvalue,minimalvalue,orothernumericalaggregates.
3.7 (Complex)EventProcessing Filtering,matching,analyzingof(real-time,time-series)data,inordertoidentifyevents.Eventsmaybesimpleorcomplex(inthesensethatunderlyingdatamaybefrommultiplelocationsand/ormayapplytolongertimeintervals,orthateventsarederivedfromotherevents).Identifiedeventsarestoredandpublishedforfurtherprocessingandaction.
3.8 DataLogistics Datastorageonanddataretrievalfrom(digital)mediainoneormultiple(distributed)systems,back-up/restore,lifecyclemanagementandarchiving,physicaltransferofdatabetweensystemsthroughcommunicationnetworks.
3.9 DataPrivacyProtection Protectingprivacyofcitizens(andotherstakeholders)bypreventingunethical,unlawful,unregulatory,unauthorizedorunwantedaccesstoanduseofdata,bothbygovernment,NGO,commercialorotherorganizationsandindividuals.Thisinvolvespolicies,processes,peopleandtechnologylikeencryption,anonymization,pseudonymizationanddatausagemonitoring.RefertoEUDataProtectionActandotherrelevantEU,memberstateorlocallegislationforfullcoverageofrequirementsforthiscapability.
3.10 DataSecurityManagement Managingconfidentiality,integrityandavailabilityofdata,bymeansofsecuritypolicies,processes,peopleandtechnologiesforuserauthentication,authorization(functionalanddataperspective),securityzoning,intruderdetectionetc.:seealsosecurityrelatedinthe‘commonservicescapabilities’layer.
3.11 DataAssuranceManagement
Monitor,validateand–ifneededandpossible-improvedataquality,inaspectslikecompleteness,validity,consistency,timeliness,
Page 31
31 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Category Nr Capability Descriptionaccuracy,compliance(wrtregulationsorstandards),duringdatarecording/entryand/orduringfurtherdataprocessing.
3.12 DataModelling Structuringofdataintermsofidentifyingdataentitiesorclasses,theirattributesorpropertiesandrelationshipsorassociationsbetweenthem.Ofteninrepresentinglogicalortechnicaldatastructuresinentity-relationorobjectorientedclassdiagrams.
3.13 DataDiscovery Discoveringtheexistenceofcertaindataordatasetsand/orexploringdatainordertounderstanddatastructuresandcharacteristics,e.g.likecertainpatternstoidentifycorrelationsortomakepredictions.Explorationmaybevisuallyforhumanprocessingand/orautomatedbyapplyingmachinelearning/dataminingalgorithms.
3.14 (Open)DataPublication Makingdataavailableto‘dataconsumers’toeitherarestrictedsetofactors(peopleorsystems)oropentoanyactor.Datapublicationmayoccurinseveraldataformats(preferablystandardsbased),inreal-timeorbatchoriented,andthroughseveralcommunicationchannelsandprotocols.
3.15 MetadataManagement Managing‘dataaboutdata’,includingdatasemantics(meaning,definitions,conceptsandrelations),dataownership,dataprivacyanddataconfidentialityclassification,dataqualityindicators,datalineage(originofdataandhowdataisderivedfromotherdata),datausagestatistics,andsoon.
3.16 Master&ReferenceDataManagement
Managing‘slowlychanging’,non-transactionalandnon-timeseriesdata,typicallyaboutactorsandobjectsandtheircoreattributes.Referencedataismostlydatatocategorize,grouporaggregateotherdata.Typicallymasterandreferencedataareusedinmanysystemsandcontexts,andshouldpreferablybekeptconsistentandsynchronized.
3.17 Analytics Theprocessofanalyzingdatafordescriptive(whathappens),predictive(whatwillhappen)orprescriptive(whatisbesttohappen)purposes.Mayinvolvevisualization,statistical,geospatial,machinelearningandothertechniques.
3.18 Reporting&Dashboarding Publishingtheresultsof(descriptive)analytics,oftenbasedon(key)performanceindicatorswiththeiractual,predicted,benchmarked,planned/budgetedorexpectedmeasures,andcontextualizedwithlocation,time,groupor
Page 32
32 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Category Nr Capability Descriptionothercategorydata.Possiblyformallyvalidatedorcertifiedby(3rdparty)audit/controlfunctions.
3.19 (Geo)Visualization Visualizingdataor(analytics)insightsderivedfromdata,ingraphical,infographical,geographicalorotherformatsonsmall(mobile)toverylarge(publiccommunication)2D-screens,orin3Dvirtualoraugmentedreality.Preferablyinadynamicalwaywithactorinteractionsupport(zoom,pan,filter,layering,…).
3.20 Semi-/UnstructuredDataManagement
Additionaldatamanagementcapabilitiesthatarespecifictosemi-structuredorunstructureddata,liketext,sound,images,videosorother.Thismayincludetheuseofunstructureddataanalysis(e.g.textmining)thatmaybeappliedforautomatedmetadataclassificationorotherpurposes.
3.21 IntegralSearch&Navigation Enhancingthefindabilityandaccessibilityofbothstructuredandunstructureddatabyofferingthepossibilityofsearching(bykeywords)and/ornavigating(bybrowsingthroughcategories),preferablyacrossdifferentdatasourcesfrompossiblymultipleurbanactorsandorganizations.
3.22 DataRecording Facilitating‘systemsofengagement’likemobileappsorwebsitestorecorddatainasafe,secureandprivacyabidingway,thatwascreatedbytheirusers/visitors.Thisfacilitatesaeasierandmorespeedilyinnovationprocessesfornew(lightweight,start-upcreated)urbanapplications,thatotherwisewouldrequiretheirown‘datarecordingback-site’.Thisalsoincludes‘datawriteback’servicesforintelligenceoranalyticalapplications.,forinstancetorecorddataaboutwhatifscenarios,budgetsorprognosis.
4. 4.1 DataExchange Exchangingdatabetweensystems,typicallyfrommultiplepublicandprivateorganizations,inacertain(standard)format,usingoneormoreprotocols.Mayrequiretransformationofdatabetweensenderandreceiver.
4.2 Messaging Theprocessofcommunicationbetweensystemsbysendingandreceivingmessages,representingrequestsorresponses,thatcanbeprocessedautomatically.Thisincludesmessagequeuing,brokering,andpublish/subscribeservices.
4.3 LoadBalancing Distributethe‘load’onrequiredresourcesforprocessinginanevenlymanner,basedonthe
Page 33
33 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Category Nr Capability Descriptionactualavailabilityof(system)resources,assumingthattherearealternativestochoosefrom.
4.4 (Open)APIManagement Managementofapplicationprograminterfaces(APIs),includingregistration,publication,usagepolicies,accesscontrol,usagestatistics.APIsprovideautomatedaccessfromonesystemtofunctionalityordatainothersystems.Suchaccessmayberestrictedtoe.g.internalactorsoropentobroadergroupsofactors.
4.5 RulesManagement Managingrulesforautomatedprocessing,thatrepresentbusinesslogic.Suchrulesmaybeaboutvalidationofdataentry,processorderandexceptions,authorizationpoliciesorother‘logic’.
4.6 EventManagement Manageeventsthatwereidentifiedby(complex)eventprocessing(seelayer3)oreventsfromothersources,likeeventsderivedfromadministrativetransactions,triggeredby(business)rulesoreventsreceivedfromexternalsources.Anysucheventsmayrequiretheinvocationofaprocesstodealwiththeevent,analertsenttohumanbeingsorsystems,orotherresponses.
4.7 TransactionManagement Managingtransactionswithinandbetweenorganizationsaccordingtoapplicablelegislation,contractsand/orotherrules.Typicallythisrequirestheconsistentandcompleterecordingoftransactionsinoneormoresystems,maintainingsynchronicityandconsistencybetweenmultiplesystemsorledgersandassociatedbalancesandaggregates.
4.8 ProcessOrchestrationandMonitoring
Automatedmonitoringandexecutionof(business)processes,basedonprocessflowmodelsandrules.Ofteninvolvinginteractionwithmultipleactors(systemsand/orpeople).
4.9 (API)ServiceManagement Managingservices(e.g.APIs,opendatapublications,dataexchanges,transactionmanagementsupportorothermorehigherlevelservices)bykeepingaservice‘catalog’,serviceprovisioning,servicelifecyclemanagement(versioning,upgrades,termination),servicecontractmanagementandmonitoring,servicesubscriptionmanagement,andsoon.
4.10 Publish,Subscription&NotificationManagement
Basedoneventsorpublicationsbyprivateorpublicurbanactors,otherhumanorsystemactorsmayreceivenotificationsoftheoccurrenceofsucheventsorpublications,possiblydependingoncertaincriteriaorrules,andthroughadiversityofcommunication
Page 34
34 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Category Nr Capability Descriptionchannels(messaging,events,e-mail,SMS,etc).
4.11 Collaboration,Communication&(Social)Media
Provisioningof(digital)facilitiesandservicesforthepurposeofcollaborationbetweenprivateandpublicactors,includingexplicitlyfacilitiesforcitizenparticipation.Thesefacilitiesmayrangefromcommunicationthroughseveral,includingsocialmediato(digital)spacesthatallowactorsfromdifferentorganizationsandgroupstoworkcloselytogether,possiblyinthecontextofSCCprojects.
4.12 Personalization Offeringofservices(includingdata,functionality,andHCIconfigurations)thataretargetedandtailoredtowardindividualorgroupsofactors,explicitlyrespectingallprivacy,securityandotherrelevantlegislation,policiesandrules.
4.13 EcosystemMarketPlace Platformandprocessestofacilitatethepublicationofapps/applications,(open)datasetsorotherservicesbyprivateorpublicurbanactors,andtheirusage/consumption,includingcontracting,licensing,authorization,transactionprocessingetc.Mayalsoincludesomeformofqualitymonitoringand/orpromotion,byapplyingstandards,designcriteria/guidelinesetc.
5. 5.1 BusinessModels,Procurement&Funding
IntegratinglocalsolutionsinanEUandglobalmarket.Createnew‘businessmodels’andpromotesuccessful‘businessmodels’,especiallythoseinlinewiththegeneralpoliciesandgoalsofaparticularcityorcommunity,leveragingtheopportunitiesinimprovedcommunication,collaborationandcoordination,offeredbySCCprojectsandprocessesandthesupportingopenurbanplatform.Theseopportunitiesmayincludee.g.jointprocurementandfunding,orknowledgesharingthereof.
5.2 Standards Providingtheframeworkforconsistency,commonalityandrepeatability,withoutstiflinginnovation.Reducefrictionandimprovespeedandaccuracyincommunicationandcollaborationbetweenbothhumansandsystems.Thisentailsactivepromotionoftheuseofstandards(global,EU,nationalorsectoral)orcoordinationofstandardizationeffortsacrosssectors,organizations,departmentsandotheractorsinthecityandcommunityecosystem.
5.3 OpenData Understandthegrowingpoolsofdata;makingitaccessible–yetrespectingprivacy.Supportandoperationalizecollaboration,transparencyandcreatecross-fertilizationinnovation
Page 35
35 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Category Nr Capability Descriptionopportunitiesbetweencityandcommunityactorsbypublicationofowndataasopendata,usingopendatafromothers.Opendataispreferablyformattedanddefinedbyapplyingrelevantstandards,includingstandardsforlinkeddata/semanticweb.Usefeedbackfromopendatapublicationsfordataqualityimprovement.Facilitateandpropelinnovation,basedonopendata,e.g.byorganizingopendataapplicationcontestsor“hackathons’’.
5.4 Metrics&Indicators(PerformanceManagement)
Enablingcitiestodemonstrateperformancegainsinacomparablemanner,basedonwelldefined(benchmark)metrics&indicators.TypicallytheseincludeEUclimategoalsrelatedmetrics&indicators,likeCO2footprint.
5.5 KnowledgeSharing Acceleratethequalityofsharingofexperiencetobuildcapacitytoinnovateanddeliver.Supportingknowledgesharingine.g.projectsforinnovationorshareddeliveryoperations,betweenactorsandorganizationsinacity’secosystem,bothpublicandprivate,bothcitizensandexpertsorotherknowledge‘producers’or‘consumers’.Thisentails(social)facilitationofknowledgesharingbetweenpeople,pro-activeandadaptivecommunication,andinformationsharing,bothadhocandinstructuralandautomatedways.
5.6 IntegratedPlanning Workacrosssectorandadministrativeboundaries,andmanagetemporalgoals.Optimizationofprocessestoe.g.reducecosts,socialimpactorenvironmentalimpact,byimprovingplanningor(andscheduling)across(administrative)disciplinesandsectorsthatareinvolvedincity/communityactivities.Mayrangefromlongtermplanning,basedonintegratedpredictions(e.g.bettercoordinationofdistrictbuilding,utilityinfrastructure,publictransportationandroadworkconstruction)tooperationalschedulingandreal-timesituationalawareness(e.g.quickendispatchofemergencyservicesbydynamictrafficmanagement/trafficlightadaptation).
5.7 Policy&RegulationManagement
Createtheenablingenvironmenttoaccelerateimprovement.E.g.byreducingadministrativeburdensforinnovation,orbyimprovingintegralaccessibility,byreducingthenumberorbyremovinginconsistenciesbetweenrulesandregulationsfromdifferentpolicyperspectives(building,environment,safety,..).Anotherexamplehereistheautomatedexposure
Page 36
36 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Category Nr Capability Description(throughAPImanagement)ofapplicablerulesandregulations,tobeusedbycommercialpartieslikee.g.carsharingorhouse/roomsharingplatformproviders,thatpossiblyoperateinmultiplecountriesand/orcities,andhavetodealwithmultiplerulesthatmaydifferpercityordistrict.
6. 6.1 SustainableUrbanMobility• Chargepoint
management• Tariffmanagement• Locationmanagement• Settlement• Etc.
Improvingbothurbanmobilityandsustainability.Thismayentailcross-modalplanning(air,road,rail,water)ofinfrastructureandtransportationcapacityandoperationaloptimizationofactualtransportofpeopleandgoods.Itisalsoaboutinnovationslikee.g.electrictransportationandcarsharing.
6.2 SustainableDistricts&BuiltEnvironment
• Planning• Design• TransactiveEnergy
Management• Etc
Thebuiltenvironmentcanbecomemoresustainableinmanyways.Theseincludesmarthomesandsmartbuildingsforenergyusageandemissionreduction.
6.3 IntegratedInfrastructure&Processes
• IntelligentLightingManagement
• MultimodalTransportationManagement
• CityInformationManagement
• Etc.
Improvingefficiency,effectiveness,safetyandreducingsocial,environmentalorotherimpactoftheinstallation,inspection,maintenance,removalandoperationsofinfrastructureandcity/communityassetsingeneral,acrosssectorsanddomains(e.g.water,energy,gas,publictransportation,roadtraffic,…).E.g.bycoordinatedplanning(locationandtime)ofactivitiesinordertoreduceimpactofactivities,bycombiningconditiondatatooptimizefailureprediction,orothercross-sectorcross-assetoptimizations.
7 7.1 StrategicStakeholderEngagement
Theabilitytoengagewithrelevantstakeholderstospecificallydefinethelegitimacy,influenceandurgencyofstakeholders,toprioritizethevariousinterests,andtojointlydefinetheroadmapandintendedsystemoutcomes.
7.2 UserExperienceManagement
Designofthewayusernavigatethroughanapplication,includingergonomicsofhowinformationispresentedandvisualizedtohumansonanydevice
Page 37
37 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Category Nr Capability Description 7.3 CitizenFocus Includecitizensintotheprocessasanintegral
actorfortransformation.Thisentailsseveralaspects,includingpersonalizedomni-channelinteraction,withmultiplecitydepartmentsandotherorganizations.Citiesmaykeeptrackofpreferences,profilesandothernot-only-administrativecharacteristicsofcitizensandotheractorsin‘urbanactormanagement’,providedthattheprivacyandpossiblesharingofactor-specificdataisinfullcontrolofdataowners;eachandeveryindividualactor,andofcourseisincompliancewithprivacylawsandregulations.Actorsshouldbeabletohavecontrolinwhichspecificpublicorprivateorganizationsmayhaveaccesstotheirpersonalorprofiledata,balancingtheirprivacywithotherpersonalgoals(e.geconomicbenefitsthatmayariseifsomeonedecidestosharedatawithcommercialparties).
7.4 Public–PrivateCollaboration
Theabilitytodefineandencouragethedevelopmentofpublic-privatepartnershipsthatcansupportspecificofgenericinitiativeswithinthescopeoftheUrbanPlatform.Theabilitytomanagetheco-operativearrangementsbetweenoneormorepublicandprivatepartners,typicallyofalongtermnature.
7.5 StrategicGoalsManagement Theabilitytodefinelong,midandshorttermgoalsforachievingsmartcitiesandsocietiesviathedeploymentofanopenurbanplatform,includingmetricsandaprocessthathelpsacitymovetowarditsstatedgoalsbykeepingexistinginitiativessatisfied,andrecruitingnewinitiativesnecessary,inaresponsibleandethicalway.
8 8.1 SecurityGovernance Thecapabilityofestablishingandmaintainingaframeworkandsupportingmanagementstructureandprocessestoprovideassurancethatinformationsecuritystrategiesarealignedwithandsupportbusinessobjectives,areconsistentwithapplicablelawsandregulationsthroughadherencetopoliciesandinternalcontrols,andprovideassignmentofresponsibility,allinanefforttomanagerisk.
8.2 AccessControl Thecapabilitytomanagegeneralsystemaccesscontrolthatincludesauthorization,authentication,accessapprovalandaudit.
8.3 Privacy&SecurityRiskManagement
Thecapabilitytoidentify,assessandprioritizeprivacy&securityrelatedrisks,followedbyacoordinatedandeconomicalapplicationofresourcestominimize,monitorandcontrolthe
Page 38
38 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Category Nr Capability Descriptionprobabilityand/orimpactofunforeseenevents.
8.4 Auditing Thecapabilitytomonitorandrecordselectedoperationalactionsfrombothapplicationandadministrativeusers.Youcanauditvariouskindsofactionsrelatedtodataaccessandupdates,configurationchanges,administrativeactions,codeexecution,andchangestoaccesscontrol.Youcanauditbothsuccessfulandfailedactivities.
8.5 Cryptography Thecapabilitytohaveanindispensablemeasureforprotectinginformationincomputersystems.Cryptographyisamethodofstoringandtransmittingdatainaparticularformsothatonlythoseforwhomitisintendedcanreadandprocessit.
9 9.1 OperationsCenter Facilitiesforintegralmonitoringand/orcontrolofprocessesandtheirassociatedactorsandobjects,bringingtogethermanyothercapabilities(includingdatafusion,(complex)eventprocessing,analytics,visualizations,collaboration,communication&(social)mediaandprocessorchestration&monitoring)forabroadvarietyofapplications.
9.2 ServiceManagement Thecapabilityofperformingasetofactivities–directedbypolicies,organizedandstructuredinprocessesandsupportingprocedures–thatareperformedbyanorganizationtoplan,design,deliver,operateandcontrolinformationtechnology(IT)servicesofferedtocustomers.
9.3 ChannelManagement Thecapabilitytoperformvarioustechniquesandstrategiestoreachthewidestpossiblecustomerbasewiththeeffectiveuseofcontactchannels.Thechannelsarenothingbutwaysoroutletstomarketandsellproducts.Theultimateaimistodevelopabetterrelationshipbetweenthecustomerandtheproductorservice.
9.4 HumanComputerInteraction
Definesthewayhumansinteractwithdifferentdevicesindifferentplaces,timesandcontexts.
9.5 MarketInteraction Thecapabilityofinteractingwiththemarketinamoreorlessstandardizedmannerbasedonopenstandards
9.6 Third-PartyInteraction Thecapabilityofinteractingwithpartnersinanecosysteminamoreorlessstandardizedmannerbasedonopenstandards
Table3.DescriptionofCapabilitiesperLayer
Page 39
39 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
4.3OPENURBANPLATFORMDESIGNPRINCIPLESInadditiontoexistingandgenerallyavailabledesignprinciples,andpartiallyderivedfromtheprinciplesinsection3.2butnowappliedatOpenUrbanPlatformlevel,WS2hasidentifiedthefollowingadditionaldesignprinciplesinthecontextofopenurbanplatforms.
1. Alayeredapproachtowardsarchitectureisdesirable,toensureacommonandvaluabledecompositionoflogicalclusters,withinandbetweenstandardizationmusttakeplace(seealsotherecommendeduseofpivotalpointsofinteroperabilityinsection4.4)
2. Applications(ormodulesthereof)withintheopenurbanplatformmustbelinkedtothecapabilities(possiblywithmany-to-manyrelationsbetweencapabilitiesandapplications/modules)asspecifiedinthecurrentreferencearchitecture,toe.g.promoteconsistency,preventoverlapandsupportknowledgeexchangeorevenre-useacrosscities.
3. Thearchitectureoftheopenurbanplatformshouldallowandcertainlynothinderincremental,iterativeevolutionaryapproachesforimplementationofopenurbanplatforms,typicallystartingbyfocusingonexistingopportunities/painpointsandthenincrementallyfurtherexpandingtheplatformovertime.
4. Openurbanplatformsshouldbebasedasmuchaspossibleonopenstandards,preferablybasedonlarge-scaledeployments.Especially,betweenthevariouslayersinanurbanplatform,standardsarepromotedtosupportflexibilityandprevente.g.vendorlock-inn(allowingscenariosinwhichmultiplevendorssupplydifferentpartsormodulesoftheplatform,thatstillworktogetherwithoutrequiringcustomization).
5. Modularity:thearchitectureoftheopenurbanplatformshouldenablecitiestouseanddeployvarious(combinations)ofmodulesor‘components’intheopenurbanplatform,notrequiringacomplete‘bigbang’implementationofanopenurbanplatform.
6. OpenUrbanplatformsmustbeabletointegratewithbothnewandexistingsystems(e.g.includingsmartcitysolutionapps/applicationsthatarebuiltontopoforuseservicesprovidedbytheopenurbanplatform,e.g.includingcommunication/IoTsystemsorsensornetworks)takingintoaccountthatinmostcasesthereisno‘greenfield’.
7. Openurbanplatformsshouldfocusoninteroperability(dataformats,protocols)betweenthevariousdefinedlayers,andnotsomuchwithincertainlayers
8. Privacy&Securityareintegralpartofanyopenurbanplatformandtheirarchitecture(P&SbyDesign)
9. Apace-layeredapproachispromoted(i.e.recognizingthatsomemodulesorcertainlayerschangefasterthanthoseinotherlayers)
10. Urbandataiscurrentlyoftenunder-utilized,andthenofteninasingleverticalapplication.Despitesynergeticopportunities,dataishardlyusedacrossverticaldomains.Animportantfocusareaofurbanplatformsshouldthereforebeonharmonizationofdatafromdifferentdomainsanddatalogistics
11. UrbanPlatformsshouldpromoteandfacilitatethepublicationof(Linked)OpenData.12. Animportantfocusareaofurbanplatformsshouldbeon‘collaboration’and‘sharing’
processesacrossdomainsvs.“singleentity/domainprocesses’Inaddition,anumberofgeneralobservationsandrecommendationshavebeenidentified:
• Whendesigningandimplementinganopenurbanplatform,adopting/reusingexistingpublicinfrastructuresshouldtobeconsidered
• CitizensandotherstakeholdersneedtobeabletomigratethruEUwithouthavingacompletelynewsetupofitsactiveparticipationofanurbanplatform(no-barrierapproach)–movingfromcityAtoBshouldbeaseasyaspossible,whenitcomestoconnectingtotheurbanplatformsofthesecities,eveniftheseplatformsaredifferentintermsoftechnology,supplierorotherwise.
• IoT-basedusecases(usecasesthatdependondigitalsensors/actuators)providethe
Page 40
40 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
highestdemandontheuseofurbanplatforms–communicationbandwidthandgeneralplatformcapacityneededtorunsmartcityinitiativeswillmostprobablyincreaseintheforthcomingyears
• Itisrecommendedtodistinguishbetweencommunicationsandnetwork,wheredifferentstandardscanandwillapply(alongthelinesoftheOSI7layers5)
• Usecasesor‘smartcityservices’thatarebasedontheopenurbanplatformaretypicallynotaimedatasingle‘targetcitizen,butata‘communityofcitizens’
Lookingatthecapabilitymapandprinciples,wehaveidentifiedseveralDesignPatternsthatwillsupportmoreefficient,coherentand/orstandardizeddeploymentofsolutions.TheseDesignPatternsfocusmainlyondataandinteroperability,reflectingthemainfocusareasofanopenurbanplatform.ThefollowingDesignPatternshavebeenidentified:Number DesignPattern ReasoningDePa.1 Allservicesareexposedviastandardizedsmall
services(APIs)throughouttheapplicationlandscape
Weprefersmall,reusableandstableservicesaboveextensiveservices.Duetothefactthatthepotentialofreusingsmallservicestomeetneedsismuchhigherthanaspecificbutlargeservice.Itwillbeeasiertohaveabest-of-breed(vendor-agnostic)approachtosolutions.Thismeansweaimatsmallservicesthatareverygoodinonething.Wedonotpreferrichservicesinwhichuserdonothavetoaddmuchfunctionalitytohaveavaluableservice.Thiswouldresultinatightercouplingbetweensystems,whichobstructstime-to-market
DePa.2 PrivacyandSecurityisnotanaddontocomponents,butanintegralpartofanycomposedsolution
Avendorthatoffersaservicemusthavedevelopedthatserviceinsuchawaythatitadherestoaminimalsetofprivacy&securityrequirements.Securityistoooftenanaddonwhichinterfereswiththerunningoftheservice.
DePa.3 Processoverdata(NBunderdispute)
Insteadofthe‘exchangeofdata’wepreferthe‘offeringofaprocess’.Byofferingtheentireprocessandmakethisexplicit,ensuringdataintegrityiseasier.Besides,authorizationismoresimple.Justofferingdataasaserviceisnotgoodenough.
DePa.4 APIsthatareexposedandconsumedmustadheretoaminimumsetofrequirements
Adheringtonon-functionalrequirementswillensureasounddeploymentofAPIsthatareaggregatedintoonebusinessservice.Theseare:
• Security(authenticationandauthorization)• Re-usability• Interoperability• QualityofService(e.g.ratelimiting)• Monitoring• Scalability• Availability
DePa.5 Devicesneedtoadheretoaminimumsetofstandards
Inordertoensurethatdevicesareeasilyintegratedinprocessesthatareneededinasmartcityorcommunity,aminimumsetofstandardstoadheretoisrequired.These
5 https://en.wikipedia.org/wiki/OSI_model
Page 41
41 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Number DesignPattern Reasoningare:
• IP-v4orIP-v6• IP-Sec
Table4.DesignPatternswithintheReferenceArchitecture4.4OPENURBANPLATFORM-INFORMATIONSYSTEMSARCHITECTUREAsstatedinchapters2and3,theintentionofthisprojectandreferencearchitectureistobevendorandprojectagnostic,notprescribinganyspecifictechnology,productorsolution.Therefore,topreventanyunintendedpreference,werestrainourdescriptionofaninformationsystemsarchitectureinthiscontext,andlimitourselvestoconsiderations,recommendations,examplemodelsandotherartefacts,asinputforcitiesandcommunities(orsuppliersandserviceproviders)toproducetheirowninformationsystemarchitecture.Ingeneral,theinformationsystemsarchitectureisconsideredhereasadesignofthetechnologyrequiredforrealizingtheopenurbanplatformcapabilitiesasdescribedbeforeinthischapter.Pleasenotethatinordertorealizecapabilities,technologyaloneisnotenough–technologiesmustbeembeddedwithinprocessesandbemadeavailableforpeoplethatuse,manageorplayotherrolesthatarenecessarytorealizeacapability.Inaddition,itshouldbenotedthatnotallcapabilitiesarenecessaryineachandeverySCCcontextduringalltimes.Rather,werecommendaphasedandincrementalapproach.Thisimpliesthattheinformationsystemsarchitecture,likeeverythingelserequiredtofulfillcapabilities,isnotastaticcollectionofartefacts,butmustbeadaptedovertimeandwitheachincrement,ascapabilitiesarebeingaddedtoacontextspecificopenurbanplatform.Also,importantly,theinformationsystemsarchitecturedoesnotnecessarilycorrespondtoasinglesystem.Infact,itismuchmorelikelyinpracticethatanopenurbanplatformanditscapabilitiesarerealizedbyavarietyofsystems.Thesemayincludenewlybuiltsystemsorexistingsystemsthatareadaptedtobecomepartoftheoverallopenurbanplatform,thelatterineffectbeinga‘systemofsystems’.TheInformationSystemsArchitectureisconsideredherefromtwoperspectivesandcorrespondingarchitecturesthatshouldbemostprominentinanyinformationsystemsarchitectureofanopenurbanplatform:thedataarchitectureandtheapplicationarchitecture.Toproducethesearchitecture,artefactsarecreatedinordertodescribethedesignofanopenurbanplatform.TheartefactsdiscussedherehavebeenadaptedfrommoreformaldefinitionscontainedinISO/IEC42010:2007,andbasedonthedescriptionsdeliveredbyTheOpenGroup.Thefollowingfigureshowstheartefactsthatareassociatedwiththeir“corecontentmetamodel”andeachofthecontentextensions.
Page 42
42 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Figure9.ArtefactsAssociatedwiththeCoreContentMetamodelandExtensions6
Thespecificclassesofartefactsareasfollows:
• Catalogsarelistsofbuildingblocks.• Matricesshowtherelationshipsbetweenbuildingblocksofspecifictypes.• Diagramspresentbuildingblocksplustheirrelationshipsandinterconnectionsinagraphical
waythatsupportseffectivestakeholdercommunication.RegardingtheInformationSystemsArchitectureandespeciallyitsunderlyingdataarchitecture(DA)andapplicationarchitecture(AA),thefollowingartefactsarerecommendedasaminimumforanOpenUrbanPlatform,usingelementsofthereferencearchitectureasastartingpoint.Artefact ElementCatalogues • PrinciplesCatalog
• DataEntity/DataComponentCatalog(DA)• ApplicationPortfolioCatalog(AA)• Interface(API)Catalog(AA)
Matrices • DataEntity/BusinessFunctionMatrix(NB(NBa.k.a.DataEntity/CapabilityMatrix)(DA)
• Application/OrganizationMatrix(AA)• Role/ApplicationMatrix(AA)• Application/FunctionMatrix(NBa.k.a.Application/Capability
6 Source:TheOpenGroup
Page 43
43 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Artefact ElementMatrix)(AA)
• ApplicationInteractionMatrix(AA)CoreDiagrams • SolutionConceptDiagram(AA)
• ConceptualDataDiagram(DA)• ApplicationCommunicationsDiagram(AA)• ApplicationandUserLocationDiagram(AA)• ApplicationUseCaseDiagram(AA)
ExtensionDiagrams(optional) • EnterpriseManageabilityDiagram• Process/ApplicationRealizationDiagram• SoftwareEngineeringDiagram• ApplicationMigrationDiagram• SoftwareDistributionDiagram
CoreDiagrams • ProjectContextDiagram• BenefitsDiagram
Table5.RecommendedArchitecturalArtefactsforanOpenUrbanPlatformDATAARCHITECTUREMostSCCinitiativeshave‘data’ascommonkeychallengeattheircore.Thischallengetypicallyhasthefollowingaspects:
• Dataisrecordedandstoredindifferentplaces,organizations,systems,withdifferenttechnologies,syntaxand(implicit)semantics.
• Datainteroperabilityisnogiven,andstillneedstobeachievedformanySCCusecaseswherevalueisoftendependingontheverycombinationandsubsequentanalysisofdatafromdifferentsources.
• Thereisaclearneedforcommondatasemanticsaturbanplatformlevel.Thiswillhighlyfacilitatetheexchangeandcommonuseofdata.Themoresoincaseswherereal-timesharingofdataisrequired,hardlyallowingtimefordatatransformationsandconversions.And,ingeneral,thebenefitsofcombiningdatafromdifferent(sub)domainswillyielddeeperinsightorwillimprovepredictions.Or,toputitmorenegatively,therisksthatcomefromthedifficultiesincombiningdatafromdifferent(sub)domains,includetheriskofmisinterpretingdatafromdifferent(sub)domains,whichmayleadtounintentionalorunconsciousmistakesintheanalysisofdataandthesubsequentinsights,decisionsandactions.Thisinturnmayleadtorealsafetyandsecurityrisks,missedopportunities,lesserperformanceofcities&communitiesintermsofeconomy,innovation,traffic,health,welfareandotherpolicyorinterestareas,includingthosethataffectthecompetitivestrengthofanycityandcommunity.(NBthebenefitsofcommonunderstandingdonotonlyapplytoautomateddataexchange,butmayalsofacilitatehumancommunicationandhencecollaboration,mutualunderstandingandsocialcohesionbetweendifferentactorsorgroupsofactors)
• Dataqualityisoftenunknownorinsufficient.Often,lackofqualityonlybecomesapparentwhenthedataisusedoutsidetheoriginaldatarecordingprocess.DataqualityissuesmayberealshowstoppersinSCCinitiatives.
• Dependingontheusecase,dataanalyticsfordescriptive,predictiveandprescriptivepurposescanbehighlycomplex,withscarceavailabilityofdatascientists
• Evermoredataiscollectedfromsensorsandrequirestreamingdataprocessingandreal-timeanalyticscapabilities,oftenunknownornewtoITorganizations.
• Datavolumesareincreasingexponentially.Thisisespeciallytrueforunstructuredorsemi-structureddatalikedocuments,weborsocialmediacontent,digitalpictures,videoetc.
• Informationoverloadfordataconsumersorusecaseactorshasbecomeasignificantrisk.Toimproveinformationergonomics,designthinkingandnewtechnologieslikeadvanced(e.g.3D)visualization,augmented/virtualrealityorcognitivecomputingarerequired
Page 44
44 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
• Dataownershipishighlyvariableorunclear,dataprivacyanddatasecurityarekeyconcerns,makingithardtounderstandlimitationsandgetpermissiontousedataindifferentusecases.
• SCCinitiativesarenotjustaboutconsumingandcombingdatafromothersystems.Insomeoccasionstheyalsorequireinstantaneousorveryrapid,guaranteedsynchronizationofdataamongstactors(systems,organizations,individuals)–withorwithoutatrustedcentralizedindependentbrokerfunction-tofacilitatenotonlythesharingofdata,butalsoanyinteractionsortransactionsbetweenactors,includingthoseofaneconomicalnature,possiblyrequiringfinancialorotherreconciliation,possiblywithinthecontextthatisdescribedandsettledinacontract.
• Notonlythedataitselfmustbesharedacrosssystemsandusecases,alsometadata(semantics,lineage,refreshdate,owner,quality)mustbeshared.
Inaddition,manySCCusecasesarebasedonthesameoroverlappingdata.Giventhehugeeffortstocollect,harmonize,integrateandanalysisofdata,theprotectionofprivacyandtheneedforconsistencyofdataacrossdifferentusecases,tonamejustafewmajorconcerns,itiskeythatdataissharedacrossusecases,byapplyingacommonurbanplatformorcity’sdatamarketplace:
Thecity’sdatamarketplacewillcontainvariouskindsofdata,whichtakentogetherprovideacommonoperatingpicture.
Figure10.CommonOperatingModelforData
conventional utility systems cannot cope with this data diversity and endless stream of all types, shapes and sizes
creating a single, centralized view with tagged data – accessible to many, and for many use cases, that is the key to success
multichannel customer interactions
smart grid equipment
home automation
weathersocial
sensors
spatial
smart meters
consumers’ usage behavior
open data
customer information
Page 45
45 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Sidenoteonthegrowingrelevanceofbigdataandadvanced&real-timeanalyticsforcitiesasincreasinglycomplexsystemsGlobalization,increasingculturaldiversity,ongoingtechnologicalinnovations,resultingamongstothersindramaticchangesinsocietaltransparencyandthewayandfrequencyofcommunicationbetweenpeople,areallfactorsthataredrivingtheevergreaterintensityofinteractionsbetweenanevergreaterdiversityofactors,leadingtoincreasingcomplexityinanevermorenetworkedworld.Systemslikecitiesarenolongermostlystaticandinequilibrium,controllableinatop-downfashion.Incontrast,increasingcomplexity,fromtheleveloftechnicalsystemstothelevelofsocialsystemslikecitiesandtheeconomyatlarge,requiresamoredetailedunderstandingofthe(city)systemstateand(city)systemdynamics.Citiesareincreasinglylesswellunderstandable,letalonemanageable,byinfrequentandhighlevelmeasurementswhichaverageouttheevermorerelevantcitysystemdynamics.Amoredetailedandmorefrequent‘sensing’willallowpolicymakersandmanagerstoinfluenceorfacilitatethecitytowardsdesiredstates–orawayfromunwantedstates-inamorepro-activeandeffectivemanner.Atypicalexampleistheurbantrafficsystem:understandingtheaveragenumberorlengthoftrafficjamsatcertainlocationson,say,amonthlybasis,willprovidesomeinsighttoimprovethetrafficsystem,e.g.byincreasingroadcapacityatsomepoints,butacontinuousinsightintotrafficflowsastheyhappeninreal-time,willincreasepossibilitiesformoreeffective,moresituationalandprobablylesscostlywaystoavoidtrafficjams,e.g.byre-routingtrafficand/orbyadvanceddynamictrafficlightapplications.Inaddition,thesameactualdatamaybeusedtooptimizeotheraspectsofthecomplexurbansystem,likee.g.parkingplaceallocation,energyusagepredictionorairqualitymanagement.Todescribethedatareferencearchitecture,whichshouldbeaddressingtheaboveaspects,weproceedasfollows,usingtheTOGAFframeworkasguide.FirstwedescribethedataintheSCCcontextintermsofa(abstract)datamodel.WethendescribethedatavaluechainasthecommondatamanagementprocessthatiscommontoallSCCinitiatives.WethenelaborateonthosepartsofthedatavaluechainthatareofparticularimportanceinanySCCinitiative,withdatainteroperabilityrequirementsbeingthemostcritical.Weconcludethissectionondataarchitecturebydescribinganumberofguidelines.DatamodelThedataaboutacityorcommunityareadigitalrepresentationor“digitaltwin”ofthephysical,socialandothercharacteristicsofthecityorcommunity.Atleastthereisacollationof“digitalbuiltenvironment”(BIM),cadaster,businessindex,address,“greenspace”,ITSinfrastructure,andutilityinfrastructure.Thisneedstobringtogethertheindoor,outdoor,above&belowgroundspaces–andincreasingly,“places”whichexistinapurelydigitalsense.DataintheSCCcontextcanbeverydifferentandhighlyvaried,bothfunctionallyandtechnically,e.g.dataismoreoftenthannotstoredinmanysystemsanddatabaseswithnon-uniformdefinitionsetc.However,fromanoverallSCCview,weseeanumberofessentialandcommoncharacteristicsofallSCCdata.Fundamentally,andfromaratherabstractperspective,allSCCdataisabouturbanprocessesinwhichurbanactorsplayarole,oftenfacilitatedbyorwiththeuseofurbanobjects.E.g.(person)transportationisanurbanprocess,withurbanactorslikepeopleandsystemsplayingroleslikedriver,passenger,inspectorsetc.usingurbanobjectslikecars,trains,trams,boats,roads,rails,stations,bridges,tunnels,trafficlights,etc.Otherexamplesofurbanprocessesinclude,nexttotransportation:education,living,legal&justice,security,safety,permits&licensing,retail,consumerservices,businessservices,trade,entertainment,culture,specialevents,sports,leisure,finance,industry&fabrication,distribution,
Page 46
46 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
energyproduction&consumption,watercleaning,management&distribution,goodslogistics,healthcare,welfare,etc.Typically,urbanprocesses,actorsandobjectsmaybecomposedoforberelatedtootherprocesses,actorsandobjects.E.g.transportationisaprocessthat–dependingontheinstanceoftheprocess-becomposedofotherprocesseslikewalking,biking,drivingandparking.Likewise,anurbanactorlikeafamily(e.g.drivinginacar)iscomposedofitsfamilymembers.Andanurbanobjectlikearoadiscomposedofroadsegments,cross-roads,carlanes,bikelanes,sidewalks,etc.Also,urbanprocesses,actorsandobjectsareoftentobecategorizedindifferenttypes.Likeeconomic,public,private,etc.processtypes.Orlikenaturalpersons,socialgroups,organizationorsystem(computer)actortypes.Orlikeinfrastructure,buildingconstruction,sensor,actuator,natural,cultural,administrative,digitalorotherobjecttypes.Inaddition,dataabouturbanprocesses,actorsandobjectscanbeconsideredfromandmaybecomplementedwithadditionaldatathatareonlyrelevantincertainperspectives.Examplesarepolitical,financial,legal/contractual,environmental,health,safety,technical(construction,inspection&maintenance,decommissioning),usage/operationalandotherperspectives.E.g.anurbanobjectlikeatrafficlightmaybecomplementedwithdataaboutitspurchasepricefromafinancialperspective,anddataaboutitsmaintenancehistoryfromatechnicalperspective.Somedatamaybecommontomultipleperspectives.Attributesofurbanprocesses,actorsorobjectsmaybegenericattributesorspecificattributespertypeand/orperroleand/orperperspective.Typicalgenericattributesarelocationandtimerelated.E.g.thestreetaddressorthegeo-coordinatesofabuilding.Locationsmaybeaspecificpointormaybemorecomplexlikeashape(e.g.thecontoursofabuilding)orastraightorcurvedline(aroadsegment).Datesandtimesarealsoverycommon,eitherasapointintimeorasatimeinterval.Notealsothatdependingontheprocess,perspectiveand/orspatial-temporalcontext,bothactorsandobjectsmayplayoneormoreroles.Anaturalpersonmayplayaroleaspassengerinonecontext,orthatofcardriverinanotherorthatofcarownerinthesameorstillanothercontext.Anobjectlikeastreetlightmayplayaroleinbothtransportationprocessandfromasecurityperspective.
Page 47
47 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Figure11.EssentialSCCDataModelfromagenericperspective
Afurtherdistinctioncanbemadeaboutthetime-varianceofdata.Referencedatae.g.typestocategorizeurbanprocesses,actorsorobjects,typicallychangesrarely(andmayevenbecandidateforacommonEUstandard).Dataaboutactorsandobjectsaretypicallyslowlychanging,andmaybeconsideredasmasterdata.Incontrast,dataaboutprocessestypicallychangesfrequently,withthefrequencydependingonthenatureoftheprocessandthelevelofdetailofwhateverisbeingmonitored/measured/controlledintheprocess,summarizedasmetricsdata.Datainprocessesisoftenrecordedintransactional(administrative,financial)systemsor,increasinglyvia(real-time)sensors.Masterdataistypicallyrecordedinregisters(catalogues).Thisisaclassofdataentities:thosethatneedtoexistonceinsomeauthoritativesense.Goodexamplesare:
• registerofbusinessesoperatinginthecity• registerofaddresses• registerofcitizens• cadaster–whoownswhat
Eachofthesemasterdataregisterswillhavegovernance,stewardship,andamaintenanceprocess.Somewillbeownedandmanagedoutsidethecity,forexamplebyanationalauthority.Thereareotherregisters/cataloguesofurbanobjectswhicharemorevolatile(changemoreoften),butwheretheoverallurbanplatformasasystemofsystemswouldbenefitfromasinglesourceoftruth:
• sensors• actuators• datasetsand/orAPIsavailableinthedatamarketplace
Thesesystemlevelregistersmaywellbeprovidedbythestandardapproachwithinthatarchitecturalcomponent,e.g.internetdomainnameresolution,mediaaccesscontrol(MAC)addressing.Metricsdata–whereacityknowswhatitwantstomeasure,thiswillprovideadditionalinformationentitiestomanage.Inmanycasesthismaybesetbyexternalreportingrequirementse.g.cleanlinessofbeaches,airquality,urbannoise.
Page 48
48 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
ExamplesofthingstomeasureincludetheUNSustainableDevelopmentGoals;theISO,IEC,ITU,andother‘smartcitymetrics’standards;variousEuropeanCommissionEnvironmentalDirectives,formanyofwhichINSPIREprovidestheinformationmodel.Workiscurrentlyon-goinginvariousSDOstomapfromthegoals,viathemetricstothedataentitiesrequiredtomeasurethem.Examplesofdataitemstosupportmeasurementinclude:
• socialsustainability:responsetimeforemergencyservices:calculatedfromincidentreports• environmentalsustainability:noiselevels:observationsvoluntarilycollectedfromcitizen’s
mobilephones;city-ownedsensormeasurements• economicsustainability:numberofemptyshopunits,calculatedfrombusinessandaddress
registers;supplementedwithcitizenobservations(activereports,andindirectthroughminingsocialmedia)
Fromthisdiscussionitisclearthateachcitywillestablishandevolveitsowncommondatamodel,containingagenericorcommonpartandinstancesofwhatwecallhere‘datacomponents’foreach(sub)domain,includingahighlevelovervieworcatalogueofdatacomponents.Thecommonthreadisthatitislikelytoinvolvemostofthetypesofdatadescribedhere.Also,thecommondatamodelprovidescommonsemanticsandthecapabilityofpublishandlinkdatainadynamicmatter,aswewillseelaterinthischapter.
Figure12.ExampleofadatacomponentasaninstantiationoftheessentialSCCdatamodel
Page 49
49 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
DatavaluechainDatamustbehandled-duetothemassiveamountsandincreasingdensityofdatathatisrequiredandexpectedtorunasmartcityorcommunity(withanurbanplatform)-inanefficientandeffectivemanner.Allthisdatahandlingfollowsthesamevaluechain,whichisthebasisforthedataarchitecture.
Figure13.DataValueChain
PartofDataValueChain
Activity Description
DataManagement
DataIngestandDataStorage
Accessandextractionofdata,inordertoperformthecollectionofdatafromanysourceandthemanagementofthatdatatransport,beforeitisstoredinamanagedmanner
DataGovernance DataCleaningandDataSecuring
Thevalidationandcleaningofdatainsuchamannerthatoutliersandanomaliesaremanaged,withinasecuredataenvironment
DataAnalytics DataDiscovery&DataAnalyses
Theaggregationanddistributionofdataforanalyticalpurposes.Analyticsandalgorithmsareappliedtothedatatoenablecities/communitiestoperform.Besidesanalytics,transactions,timeseriesandvectorialdataaremanaged
InsightsDelivery ActingonDataandAnalytics,andtheautomationofthis
Basedontheprovideddatainsightsaredelivereduponwhichcustomers,usersandeventuallysystemscan(automatically)act(takedecisiveaction)inordertoachievetheirspecificgoals.Thisisalsotheplacewhereusersexperienceoutputfromtheintelligence,transactional,operationalorgeographicalengine
Table6.DataValueChainTheDataManagementCapabilities(seeformersection)includealldatamanagement,governance,analyticsandinsightsdeliveryactivities,asafoundationtosupporttheonwardapplicationcentricandbusinessprocesscentricusesofthedatabyothercapabilities.
Page 50
50 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
DATALIFECYCLERecognizingthelifecycleofdataisanessentialpartofmanagingbusinessdatafromitsconceptionuntilitsdisposal.7Potentially,eachdataentitymayhaveadifferentlifecycle.However,itislikelythatmanyentitieswillhavesimilarlifecycles.Itmaybepossibletocreateasetofdatalifecycles,andfordataentitiestobeattachedtoparticularlifecycleswhentheyareregistered.Examplesofdatalifecyclesinclude:
• “standard”datalifecycleendorsedbyDAMA:http://www.information-management.com/news/data-management/Data-Life-Cycle-Defined-10027232-1.htmlDatacapture;datamaintenance;datasynthesis;datausage;datapublication;dataarchival;datapurging.Critique–inasmartcity/datamarketplacecontext,data“publication”generallyoccursalongsideusage,ratherthanafterwards.
• ISO15926/STEP,originallyforindustrialprocessfacilities,butrecognizedashavingwiderapplication
• W3Chascollatedvariousdatalifecycledescriptionsathttps://www.w3.org/2011/gld/wiki/GLD_Life_cycle,aspartofitsworktostandardizethedatalifecycleapplicableto‘governmentlinkeddata’.
• Technicalframeworksforcreating,reading,updatinganddeleting(CRUD)ofdata.DATAINTEROPERABILITYToachievedatainteroperability,werecommendthe(further)developmentanduseofacommonurbanontologyandtheconceptoflinked(open)data.
Figure14.Asimpleexampleoftheconceptoflinkeddata8
7TOGAFnotes
Page 51
51 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Ratherthantryingtomatchdatafromdifferentdomainsatonlyasyntacticallevel–thetraditionalapproach,werecommendthateach(sub)domainsystemsenablesitsdatatobepublishedinacommon(RDF–linkeddata)format,referringtoacommonurbanontology,specifiedintheOntologyWebLanguage(OWL),whichinturnisbasedonothergenericorspecificontologies.E.g.ontologiesonpersons,buildings,locations,etc.Seeforexamplehttp://smartcity.linkeddata.es/.Thelinkeddata(withRDFandOWL)setupstillallowslocalspecialdataelements,whilstremainingintheoverallstandardontologystructure.Evenwithtailormadeadditionstoanystandardframework,onecanstilltravelalongthepathofthestandard’snewversionsandupgrades,withouthavingtore-implementthesolutionorothersignificantefforts.Meanwhile,(sub)domainsystemscontinuetoreportontheirspecific(sub)domaine.g.crime,healthincidents,schooltruancy;thecommonurbanontologyallowsthesetobecollatedintoacommonpictureofurbanprocesses,actorsandobjects.Note:foranelaborationonOntologiespleasebereferredtothegoodworkthathasbeenestablishedwithinEspresso.
Figure15.Anexampleofaspecificarchitectureofasmartcityproject9
Pleasenotethatwedonotimplyherethatalldatashouldbemovedtoafixedandcentraldatarepositorylikeadatawarehouse.Rather,thelinkeddataor‘internetofdata’allowsamuchmoredynamicalcombinationor‘linking’ofdatafromdifferent‘publishers’,verymuchlikehyperlinksbetweenwebpages,onlymorestructuredandwithreferraltoanontologytocorrectlyinterpretthe
8Example:Dataispublished(inRDFformat)ontheinternetfromdifferentsourcesystems(colors;e.g.CDNow,weatherchanneletc.),andthenthedatacanbelinkedacrossthesesources,becauseoftheuseofacommonontology(inOWL)thatallowse.g.thebirthplaceofamusicianinonedatasettobelinkedtothecapitalcityinacountryinanotherdataset.9Validasaninstanceofthereferencearchitectureinthisdocument,positioninglinkeddataasthecentralcore,ontheonehandasacentralplacetopublishdatafromdatasources,ontheotherhandascommondataplatformforSCCappsandsystems
Page 52
52 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
data.TheresultingnetworkoflinkeddataisthefoundationofwhatispotentiallyamyriadofSCCappsandsystems.GUIDELINESTofinalizeourrecommendationsandinputforSCCstosupporttheirefforttocreateadataarchitecture,wehaveincludedanumberofguidelines.WhendeliveringamorespecificDataArchitecture,WS2statesthatthefollowingelementsneedtobeinplace:
• AcleardefinitionofwhichcomponentsinthearchitecturewillserveastheSystemofRecordorReferenceformasterdataintheUrbanPlatform
• Acity-widestandardthatallapplicationcomponentsneedtoadopt(e.g.adatamodel)• Asounddatavaluechaindecompositionofthevariouselementsinthedatamodel
ThevarioustypesofdatathatcanbemanagedwithinanOpenUrbanPlatformcanbecategorized,andwithinthatcategoryfurtherdetailed(e.g.Rawdatacanbetimeseriesbasedornon-timeseriesbased):
• AuditEvents• RawData• AnalyticsData• TransactionalData• CustomerData• ApplicationData• AssetandConfigurationData
APPLICATIONARCHITECTUREAsmentionedbefore,anelaboratedapplicationarchitectureisoutsidethescopeofthecurrentwork.However,WS2andESPRESSOdoprovideinputforcitiesandcommunities(orsuppliersandserviceproviders)toproducetheirownapplicationarchitecture.Inthischapterwefocusontheimportanttopicofinteroperabilityandprovideaverywellillustrationofanoverallsolutionconceptdiagram.WS2notonlyprovidesthisasanexample,butasaproposedwayofworkingandbasisforeverysolutionarchitectureprojectswillundertake.INTEGRATIONANDINTEROPERABILITYSTYLESIntegrationandinteroperabilityareofmajorconcerntoanyopenurbanplatform,especiallyinitsapplicationarchitecture.Inaddition,thetopicisnotlimitedtoasingleaspectlikee.g.APIsandAPImanagement,butmuchmoremustbetakenintoaccount.Thefollowingfivethemescoverthis:
1. ProcessInvocation2. DataMovement3. User-centricMovement4. ThingIntegration5. EnablingServices
Page 53
53 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Figure16.Integrationstyles
Basedontheseintegrationstyles,WS2hasestablishedaframeworkforreferenceusecasesforintegrationandinteroperability.
Figure17.Referenceusecasepatternsforintegrationandinteroperability
ThesepatternsclearlyshowthatintegrationandinteroperabilitycoversmuchmorethanAPImanagementorBusinessRulesmanagement.InordertocomeupwithLogicalandSolutionArchitectures,thatwillvarypercity,communityandproject,theaboveshownusecasepatternsshouldbeinscopewhenrealizingsolutions.
Page 54
54 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Whenlookingatinteroperability,NISThasdevelopedtheprincipleofthePivotalPointsofInteroperability(PPI)10.Thisworkhasbeenestablishedsincetoomany‘standards’aroseintheareaofsmartcitiesandIoTdevices.NISTstatesthat“therewillbenowayallofthesedeviceswillactuallybeabletototalktoeachotheruntilallthisgetssettledwitheithervictoryortruce”(quotefromInaFried,re/code2014).NISTalsostatesthatdefiningandidentifyingthePPIswithspeed,willreducethedistancetointeroperability.Ifyoustandardizeeverything,noinnovationwillbeenabled.Ifyoudonotstandardizeatall,yougetnon-interoperableclustersthatcannotbeeasilyintegrated.PPIprovidesconsensusstandardizedinterfacesthatdealwithcompositionofCPSwithoutconstraininginnovation.
Figure18.PivotalPointsofInteroperability
WS2recommendstousethePPIprincipleinsupportofachievinginteroperability.ILLUSTRATION:SOLUTIONCONCEPTDIAGRAMInthiscontext,thesolutionconceptdiagram,asoneoftherecommendedartefactsinanopenurbanplatformapplicationarchitecture,togetherwiththedataarchitecture(seeprevious)section,wouldrespondtothetechnologicalimplementationoftherequiredopenurbanplatformcapabilities,asdescribedinthisdocument.Toillustrate,wehaveincludedanexampleofapossible‘solutionconceptdiagram’asoneoftherecommendedcatalogues.ThisexampleistakenfromtheESPRESSOproject,furtheraligningtheworkbetweenthisprojectandtheESPRESSOproject.ESPRESSOincludesaSmartCityEngineeringViewthatcanbedevelopedusingaso-called‘IndustryArchitecture’.IndustryArchitecturesguidetheintegrationofcommonsystemscomponentswith
10Dr.MartinBurns(NISTSmartGridandCyber-PhysicalSystemsProgramOffice)-ETSIIoT/M2MWorkshop2016,15November2016
engineering laboratory
PPI
PPI
PPI
Pivotal Points of Interoperability (PPI)
7
Independent technology deployments
With Pivotal Points of Interoperability
Potentially large distance to interoperability
Minimize distance to interoperability
Application Diversitye.g. IPv6 address
e.g. TLS 1.2
e.g. REST APIs
e.g. Convert XML to JSON
Page 55
55 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
industry-specificcomponents,andguidethecreationofindustrysolutionsfortargetedcustomerproblemswithinaparticularindustry.AkeyelementoftheEngineeringViewisaSolutionConceptDiagram(asmentionedaboveasoneoftherecommendedartefacts)orsimilaroverviewoftheengineeringarchitecture.AsidentifiedinTOGAF,aSolutionConceptDiagramprovidesahigh-levelorientationofthesolutionthatisenvisagedinordertomeettheobjectivesofthearchitectureengagement.IncontrasttothemoreformalanddetailedarchitectureartefactsdevelopedinthesubsequentTOGAFphases,thesolutionconceptrepresentsa"pencilsketch"oftheexpectedsolutionattheoutsetoftheengagement.ThefigurebelowprovidesaninitialSmartCitiesSolutionConceptDiagram.Someelementsofthediagramaremorematureandhaveexistingstandards.Otherelementsarenewandareunderactivedevelopment,e.g.IoT.Thishigh-levelengineeringviewofaSmartCityUrbanPlatformisorganizedinlayerstypicalofaninformationsystemdeployment,heredefinedintermsof‘services’.Servicesareanabstractionofamyriadofpossibletechnicalimplementations.Pleasenotethat‘services’heredonotnecessarilycorresponddirectlyto‘capabilities’asdescribedearlierinthisdocument.Servicesareconsideredheretorepresentthepartsofoneormoreinformationsystemsthatfulfilthetechnicalrealization(notaddressingpeopleandprocessaspectsofcapabilityfulfilment)ofoneormorecapabilities,orpartsthereof.
Figure19.ESPRESSOexampleofanOpenUrbanPlatform-SolutionConceptDiagram
Page 56
56 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
Thedifferenttypesofservicesaredescribedbelow:• PositioningServices
ThePositioningServicesLayerwouldincludegeodetic,co-ordinatereferenceandglobalpositioningrelatedservices.Locationrelatedpositioningservicescouldbefulfilledviaarangeofmethodse.g.satelliteor4Gdependingonthelevelofpositionalaccuracyrequired.Thelocationpositioningservicesshouldbecapableofrecordingpositiononallscalesnecessaryforeffectivedecision-making.Forexample,meterinruralareas,cmforcitylevel,mmforbuildingsandsub-0.1mmforbuildingcomponentsandplant.
• SensingServicesTheSensingServicesLayerwouldinclude‘sensor’relatedserviceswhethertheseareInternetofThings(IoT)relateddevices,formalsurveying(land,assetmanagement,construction)methodsorcitizenbasedcrowdsourcingfromconsumerdevices.Thedatacaptureservicesshouldbecapableofcapturingallsignificantfeaturesinthebuiltandnaturalenvironmentthatarerequiredtosupportonwardbusinessprocessesandeffectivedecisionmaking.TheSensingServicesLayerwouldformanimportantbuildingblockwithinanyUrbanPlatformsandbethesourceofvarioussectorialdata,whichwouldsubsequentlybeusedwithintheDataServices,ApplicationServicesandBusinessServicesLayers.
• DataServicesTheDataServicesLayerwouldincludecoredatamanagementanddatalifecycle(e.g.ingest,assure,integrateetc.)relatedservices.Thedataservicesshouldbecapableofprovidingallthedatamanagement,processing,exploitationanddisseminationservicesrequiredtosupporttheonwardapplicationcentricandbusinessprocesscentricusesofthedataviatheApplicationServicesandBusinessServicesLayers.
• ApplicationServicesTheApplicationServicesLayerwouldincludeallthesoftwareapplicationsthatactuponthedatacomponentsprovidedviatheDataServicesLayerinordertosupporttheonwardBusinessServicesLayer.Applicationrelatedservicesshouldprovideallthefunctionalservices(e.g.analytics,reporting,datavisualisationsetc.)requiredtosupportonwardbusinessprocessandservices(e.g.wastemanagement,assetmanagement,urbanmobilityetc.).Thislayershouldencapsulate,decoupleandabstractbusinesslogicanddataaccess.Theideabehindsuchalayeristohaveanarchitecture,whichcansupportmultiplebusinessservices.
• BusinessServicesTheBusinessServicesLayerwouldincludesmartcitysectorialspecificbusinessserviceswhichwouldbeconsumedbyavarietyofconsumersandstakeholders(e.g.cityleaders,citizens,operations,andcommerceetc.).A‘businessservice’canbethoughtofasanyservicethatisdeliveredto‘customers’by‘businessunits’.Amoretraditionalexamplewouldbe,deliveryoffinancialservicestocustomersofabank,orgoodstothecustomersofaretailstore.Successfuldeliveryofbusinessservicesoftendependsononeormore‘ITservices’providedbytheApplicationServicesLayer.AbusinessservicecanconsistalmostentirelyofanITservice(e.g.anonlinebankingservice)orcanbemuchmorebusinessservicescentric(e.g.aprofessionalormanagedservice).Thebusinessserviceslayershouldbecapableofprovidingalltheoperationalandgovernanceservicesrequiredtosupportasmartcitysectorialsystem.
• ConsumersTheConsumersLayerwouldincludeanysmartcitystakeholderwhowishestointeractwithandconsumesmartcityservices.Theseconsumerscouldeitherbehumansorothersmartcitysystems(e.g.machine2machine,system2system).
Page 57
57 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
• Cross-CuttingServicesThree“vertical”orcrosscuttinglayersareincludedhere:SecurityServices,TechnologyServicesandSupportingServices,whicharenotboundtoorspecifictoagiven“horizontal”layer.Theywouldincludevariousservicesthatcouldberequiredforanyofthehorizontallayers.• SecurityServices
TheSecurityServicesLayerwouldincludeasetofstandardsecurityservicessuchasIdentifyManagement,Authentication,Authorisation,Encryption,andAuditingetc.
• TechnologyServicesTheTechnologyServicesLayerwouldincludeasetofstandardtechnologyservicessuchasIntegration,Networks&Communications,TransactionManagement&OrchestrationandComputingInfrastructure(e.g.cloud,on-premiseorhybrid)
• SupportingServicesTheSupportingServicesLayerwouldincludeasetofstandardenterprisesupportservicessuchasCollaboration,DocumentandKnowledgeManagementandBusinessIntelligence.
Page 58
58 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
APPENDIXA.ACRONYMSAcronym DescriptionADM ArchitectureDevelopmentMethodAPI ApplicationProgrammingInterfaceBSI PubliclyAvailableSpecificationCRUD CreateReadUpdateDeleteEIP EuropeanInnovationPartnershipESO EuropeanStandardisationOrganizationsESPRESSO systEmicStandardisationapPRoachtoEmpowerSmartcitieSandcOmmunitiesHAN HomeAreaNetworkIEC InternationalElectrotechnicalCommissionIP InternetProtocolISO InternationalOrganizationforStandardizationITS IntelligentTransportSystemsITU InternationalTelecommunicationUnionJTC1 JointTechnicalCommittee1KPI KeyPerformanceIndicatorsNSB NationalStandardisationBodiesOGC OpenGeospatialConsortiumPAS PubliclyAvailableSpecificationSCC SmartCitiesandCommunitiesSDO StandardsDevelopmentOrganizationsTOGAF TheOpenGroupArchitectureFrameworkW3C WorldWideWebConsortiumWGx WorkingGroupxWSx WorkStreamx
Table7.Acronyms
Page 59
59 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
APPENDIXB.REFERENCEARCHITECTURECAPABILITYMAP–LARGEVIEW
Page 60
60 EIPSCCOpenUrbanPlatformsWorkStream2ReferenceArchitecture&DesignPrinciples
APPENDIXD.DOCUMENTMETADATAB1.REVISIONHISTORYVersion Date Editors Description0.1 20May2016 JeroenScheer Firstdraftwithmainstoryline0.2 30June2016 LutzHeuser,JeroenScheer Seconddraftwithchangesandadditions
basedonfirstreview0.3 5July2016 LutzHeuser,JeroenScheer Thirddraftwithchangesandadditions
basedonreviewanddiscussionswithcoreteam,includinginputandreviewfromWS1andEspressodelegates
0.4 14September2016 JeroenScheer FourthdraftinpreparationofmeetingWS1,WS2,Espresso
0.5 20September2016 JeroenScheer FifthdraftafterreviewbycoreteamWS20.62 26September2016 JeroenScheer,Pieterden
HamerSixthdraftafterreviewbynon-coreteammembersandEspresso,releasedtoWS1,WS2andEspresso
0.7 6November2016 PieterdenHamer SeventhdraftaftermeetingwithWS1,WS2andEspressoincludingtheresultsofthetwodayonsitereviewconference
0.8 18November2016 JeroenScheer EightdraftafterreviewbycoreteamWS2andEspresso
0.9 30November2016 JeroenScheer,PieterdenHamer,LutzHeuser,BartdeLathouwer,AndyCox,PeterParslow,EvaKlien,BernhartKempen,JoachimLonien
NinthdraftafterreviewofWS2,WS1andEspresso,andaligningtheWS2andEspressoinitiativesanddocuments(wherepossiblefullyalignmentonstructure,figuresandtexts)
0.95 26January2017 JeroenScheer Minoredits,additionsinapplicationarchitecture
0.96 30March2017 PieterdenHamer Textualandstructuralchanges,basedonreviewcomments
0.98 22June2017 PieterdenHamer,BartdeLathouwer
FullalignmentwithEspresso
1.00 27September2017 JeroenScheer Finalversionafterlastreviewround
Table8.Revisionhistory
B2.STATEMENTOFORIGINALITYThisdeliverablecontainsoriginalunpublishedworkexceptwhereclearlyindicatedotherwise.Acknowledgementofpreviouslypublishedmaterialandoftheworkofothershasbeenmadethroughappropriatecitation,quotationorboth.B3.DISSEMINATIONLEVELLevel Description ApplicabilityPublic Public XRestricted/Confidential Confidential,onlyformembersoftheconsortiumandthe
CommissionServices
Table9.Disseminationlevel