eu european innovation partnership for smart cities & communities - open urban platforms...

REFERENCEARCHITECTURE&DESIGNPRINCIPLESEIPSCCWORKSTREAM2–MAINDELIVERABLESEPTEMBER27,2017

FINAL,version1.00Maineditors:LutzHeuser,JeroenScheer,PieterdenHamer,BartdeLathouwerContributors:LutzHeuser,JeroenScheer,PieterdenHamer,BartdeLathouwer,AndyCox,PeterParslow,BernhartKempen,EvaKlien,JoachimLonien

ThisdocumentispartoftheoverallprogramEIPSCCOpenUrbanPlatforms,andisproducedbySupplySideWorkStream2,andbytheHorizon2020Espressoproject.

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


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.


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.


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.


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...//


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


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


LISTOFTABLESTABLE1.USEOFREFERENCEARCHITECTUREFORVARIOUSSTAKEHOLDERS.................................................................19TABLE2.DESCRIPTIONOFOPENURBANPLATFORMCAPABILITYCATEGORIES.............................................................25TABLE3.DESCRIPTIONOFCAPABILITIESPERLAYER................................................................................................38TABLE5.DESIGNPATTERNSWITHINTHEREFERENCEARCHITECTURE.........................................................................41TABLE7.RECOMMENDEDARCHITECTURALARTEFACTSFORANOPENURBANPLATFORM............................................43TABLE6.DATAVALUECHAIN.............................................................................................................................49TABLE7.ACRONYMS........................................................................................................................................58TABLE8.REVISIONHISTORY...............................................................................................................................60TABLE9.DISSEMINATIONLEVEL.........................................................................................................................60


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.


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


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.


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


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.


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.


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


Figure4.WS2ScopeplottedonTOGAFEnterpriseContinuum

WS2recognizesthelargevarietyofuseandperspectivesonarchitecture.Todevelopthereferencearchitectureforopenurbanplatforms,WS2willthereforeadheretoTOGAFasagloballyusedandadoptedframeworkthatstandardizesvariousviewpointsandperspectives.Todevelopspecificarchitecturesandsolutionsforspecificcitiesorcommunities,werecommendtheuseofthesameframework.


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


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’


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


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· ...


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.


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


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


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


CAPABILITIESPERCATEGORYForeachcategoryasetofcapabilitieshasbeenidentified.Thesearepresentedinthepicturebelow.Theirdescriptioncanbefoundinthefollowingtable.

Figure8.EIPSCCOpenUrbanPlatformCapabilityMap–categorylevel


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


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)


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


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,


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


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


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


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


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


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


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


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


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


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


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.


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


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


• 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


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,


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.


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.


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


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.


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


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


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


Figure16.Integrationstyles

Basedontheseintegrationstyles,WS2hasestablishedaframeworkforreferenceusecasesforintegrationandinteroperability.

Figure17.Referenceusecasepatternsforintegrationandinteroperability

ThesepatternsclearlyshowthatintegrationandinteroperabilitycoversmuchmorethanAPImanagementorBusinessRulesmanagement.InordertocomeupwithLogicalandSolutionArchitectures,thatwillvarypercity,communityandproject,theaboveshownusecasepatternsshouldbeinscopewhenrealizingsolutions.


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


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


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).


• 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.


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


APPENDIXB.REFERENCEARCHITECTURECAPABILITYMAP–LARGEVIEW


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

eu european innovation partnership for smart cities & communities - open urban platforms...

Government & Nonprofit