connected corridors: i-210 pilot integrated corridor...

PARTNERS FOR ADVANCED TRANSPORTATION TECHNOLOGY INSTITUTE OF TRANSPORTATION STUDIES UNIVERSITY OF CALIFORNIA, BERKELEY

Connected Corridors: I-210 Pilot Integrated Corridor Management System

Core System High-Level Design

June 21, 2018 v 1.1

Partners for Advanced Transportation Technology works with researchers, practitioners, and industry to implement transportation research and innovation, including products and services that improve the efficiency, safety, and security of the transportation system.

I-210Pilot:CoreSystemHigh-LevelDesign

ii

Thispageleftblankintentionally


iii

TableofContents

1.Introduction...................................................................................................................................1

1.1. PurposeofDocument.............................................................................................................11.2. RelationtoSystemsEngineeringProcess................................................................................11.3. IntendedAudience..................................................................................................................21.4. DocumentOrganization..........................................................................................................2

2. AnIntroductiontoMicroservicesArchitectureonAmazonWebServices.......................................5

2.1. MicroservicesDefinition.........................................................................................................62.2. WhyUseaMicroservicesArchitecture...................................................................................82.3. UseoftheCloudandAmazonWebServices(AWS).............................................................122.4. ImpactontheDesignDocument...........................................................................................13

3. SystemPrimaryObjectivesandPurpose.......................................................................................15

3.1. ProjectGoalsandObjectives................................................................................................163.2. TechnicalCapabilitiesSought................................................................................................18

4. HighLevelDesignObjectives,Constraints,andPrinciples.............................................................21

5. CoreSystemHighLevelDesign.....................................................................................................23

5.1. MajorComponents...............................................................................................................235.2. FieldElements.......................................................................................................................245.3. DataHub...............................................................................................................................255.4. DecisionSupport...................................................................................................................275.5. CorridorManagement..........................................................................................................275.6. Primaryprocessflow.............................................................................................................30

6. DataHubDesign...........................................................................................................................33

6.1. DataSources.........................................................................................................................366.2. DataPipelines........................................................................................................................38

6.2.1. SensingDataPipeline..........................................................................................386.2.2. HeterogeneousDataPipeline..............................................................................396.2.3. HomogenousDataPipeline.................................................................................406.2.4. PipelineControl...................................................................................................416.2.5. PipelineStatusandLogging.................................................................................436.2.6. CorridorManagementSystem-DecisionSupportSystem(CMS-DSS)CommunicationsPipeline..................................................................................................44


iv

6.3. ExternalInterface/DataGateway..........................................................................................486.4. DataHubCommandGateway...............................................................................................50

6.4.1. Conductor............................................................................................................516.4.2. Camel...................................................................................................................526.4.3. ActiveMQWorkflowStatusTopic.......................................................................526.4.4. ActiveMQWorkflowTaskTopic..........................................................................526.4.5. Monitor...............................................................................................................52

7. DecisionSupportSystemDesign...................................................................................................53

7.1. DSShighleveldesign.............................................................................................................547.2. DSSInterface.........................................................................................................................557.3. ResponsePlanManagement.................................................................................................567.4. Modeling...............................................................................................................................58

7.4.1. Modelingtechniques...........................................................................................59

8. SecurityDesign.............................................................................................................................63

8.1. Minimizeattacksurface........................................................................................................638.2. Authentication......................................................................................................................648.3. DataEncryption.....................................................................................................................648.4. PrincipleofLeastPrivilege....................................................................................................648.5. Automatedsecurityandprocessmonitoring........................................................................658.6. Automatesystemlaunchprocesses......................................................................................658.7. Validateallincomingdata.....................................................................................................65

9. SystemInterfaceandMessageSystemDesign..............................................................................67

9.1. DataHubInternalMessaging................................................................................................689.1.1. DataMessagingandKafka..................................................................................689.1.2. CommandMessagingandActiveMQ..................................................................68

9.2. DSSInternalMessaging.........................................................................................................69

10.DefinitionofTerms......................................................................................................................71


v

ListofFigures

Figure1-1–SystemRequirementsSpecificationwithinSystemsEngineeringProcess................................................2Figure2-1DataPipelineMicroserviceExample............................................................................................................6Figure5-1CoreSystemHighLevelDesign..................................................................................................................23Figure5-2PrimarySystemIncidentFlow(Subsystem)...............................................................................................31Figure6-1DataHubHighLevelDesign.......................................................................................................................34Figure6-2SensingDataPipelineDesign.....................................................................................................................38Figure6-3HeterogeneousDataPipeline....................................................................................................................40Figure6-4HomogenousDataPipeline........................................................................................................................41Figure6-5PipelinePrimaryControlLayer...................................................................................................................42Figure6-6DSS-CMSDataPipelineConfigurations......................................................................................................45Figure6-7DataHubDataGateway–ActiveMQandWebServicesDesignPatterns.................................................49Figure6-8DataHubCommandGateway....................................................................................................................51Figure7-1DSSArchitecture........................................................................................................................................54Figure7-2DSSInterfaceHighLevelDesign.................................................................................................................55Figure7-3ResponsePlanManagementDesign..........................................................................................................56Figure7-4ResponsePlanManagerWorkflow............................................................................................................58Figure7-5-ModelingComponentDesign..................................................................................................................59


vi

ListofTables

Table2-1ExampleComponentTasking........................................................................................................................7Table2-2MicroserviceAdvantageExamples................................................................................................................8Table2-3AWSServiceUsage......................................................................................................................................12Table3-1–ICMSystemGoalsandObjectives............................................................................................................16Table5-1MajorSystemComponents.........................................................................................................................23Table5-2–FieldSystems............................................................................................................................................24Table5-3ResponsePlanLifecycle...............................................................................................................................28Table5-4CMSManagementCapabilities...................................................................................................................29Table6-1ICMDataSources........................................................................................................................................36Table6-2SensingPipelineDataSources.....................................................................................................................38


1

1. INTRODUCTION

ThisConnectedCorridorsHighLevelDesigndocumentprovidesthehighlevelsystemarchitectureforthesystemtobedeployedontheI-210corridor.ThesystemarchitecturedescribedhereisadirectresultoftheConnectedCorridorsSystemRequirementsdocumentandtheworkdoneatUCBerkeleyintrafficmodelingandcontrol.Thisdocumentprovidesthesystemarchitecture,highleveldesignoftheprimarysubsystems,thedecisions,assumptions,constraints,andreasoningbehindthatarchitecture,andcriticalfunctionseachsubsystemprovidesforthesystem.

Thesystem,tobepilotedalongasectionoftheI-210corridorintheSanGabrielValleyareaofLosAngelesCounty,aimstoimproveoverallcorridorperformanceduringincidents,unscheduledevents,andplannedevents.Thisistobeachievedbymoreefficientlymanagingexistingsystemsandinfrastructures,promotingcross-jurisdictionaloperations,andusingmulti-modaltrafficanddemandmanagementstrategiesthatconsiderallrelevantmodesoftransportation.

1.1. PURPOSEOFDOCUMENT

Thisdocumentprovidesthehighleveldesign,servingastheidentificationoftheprimarysubsystemsandmajorcomponentsaswellasthebasisfortheselection,development,andintegrationoftheseintoasystemthatsatisfiesthesystemrequirementsasdefinedintheSystemsRequirementsDocument.ThishighleveldesignwillgovernthetechnologyplatformanddirectionoftheI-210PilotICMSystemandserveasthebasisforotherCaltrans-ledICMeffortsstatewide.

1.2. RELATIONTOSYSTEMSENGINEERINGPROCESS

ThedevelopmentofhighleveldesignispartofthesystemsengineeringprocessthattheFederalHighwayAdministration(FHWA)requiresbefollowedfordevelopingIntelligentTransportationSystem(ITS)projectswhenfederalfundsareinvolved.Whilenotrequiredforprojectsonlyusingstateorlocalfunds,useofthesystemsengineeringprocessisstillencouragedinsuchcases.

TheoverallsystemsengineeringprocessisillustratedinFigure1-1.DevelopinghighleveldesignrepresentsthenextstepoftheSystemDefinitionandDesignphaseofaproject(Phase2inthefigure)followingthecompletionoftheSystemRequirements.HighLevelDesignistypicallyderivedfromtherequirements.Theresultingdesignelementsareinturnusedtoinformandguidethemoredetaileddesignofthevarioussystemandsubsystemcomponents.


2

Figure1-1–SystemRequirementsSpecificationwithinSystemsEngineeringProcess

1.3. INTENDEDAUDIENCE

TheprimaryaudiencefortheSystemHighLevelDesigndocumentincludespersonnelresponsiblefordesigningandimplementingtheICMsystem.TheaudiencealsoincludesindividualsfromCaltransDistrict7,CaltransHeadquarters,andtheUniversityofCalifornia,Berkeley,taskedwithprojectmanagementduties.

1.4. DOCUMENTORGANIZATION

Theremainderofthisdocumentisorganizedasfollows:

• Section2providesahighleveloverviewofmicro-servicesarchitecturesandtheuseofAmazonWebServices(AWS)usedinthedesignofthissystem

• Section3summarizestheprimarysystemobjectivesidentifiedwithintheSystemRequirementsthatshapethesystemdesign.

• Section4presentstheprimaryguidingdesignprinciplesandbaseassumptionsthatshapethesystemdesign.

• Section5presentsthekeysystemdesigncomponentsandprimarydataflows.

System Validation / Strategy Plan

System Verification Plan(System Acceptance)

Sub-system Verification Plan

(Subsystem Acceptance)

Unit/Device Test Plan

Systems Requirements

Document

Design Documents

Concept of Operations Document


3

• Section 6 presents the key system components of the Data Hub including data sources,interfaces/gatewaysandpipelines.

• Section7presentsthekeysystemcomponentsoftheDecisionSupportSystem(DSS)includingtherulesengine,modelinginterfaces,andresponseplangeneration.

• Section8presentskeysecuritydesignissuesandimplementationplans.

• Section 9 provides design information for the system interfaces and themessaging systems,describinghowinformationisexchangedwithexternalsystemsandhowitispassedbetweenandwithinsubsystems.

Inaddition,othersupportingdocumentsareavailableintheDocumentLibraryoftheConnectedCorridorswebsiteathttps://connected-corridors.berkeley.edu/resources/document-library:


4



5

2. ANINTRODUCTIONTOMICROSERVICESARCHITECTUREONAMAZONWEBSERVICES

TheConnectedCorridorssystemsoftwaredesignisnotbasedonarchitecturesanddesignpatternstypicallyfoundinthetransportationindustry.Manyoftoday’stransportationsystemshavelongproductionhistorieswithsignificantoperationalexperience,butasaresultarebasedonsystemarchitecturesandcodethathavebeeninexistenceforadecadeorlonger.Currenttransportationsystemsareoftenbasedonamoretraditionaln-tier,datacenterhostedsoftwarearchitecturewithauserinterfacelayer,applicationlayer,andrelationaldatabaselayer.Suchtraditionaldesignsarewellsuitedforsystemswithmoderatedatavolumesandlimitedsizeandscope.

TheConnectedCorridorsprogramhasbegunwithablankslate,andasaresultisnotboundtothelimitationsofanexistingsystem.Instead,ConnectedCorridorsusesamorerecentsoftwarearchitectureandassociateddesignpatternsmoreoftenfoundinthebigdataworld,moresuitedforhighdatavolumesandreal-timeprocessingatextremelylargescale.ThedesignoftheI-210systemisbuiltspecificallyformulti-jurisdictionalenvironments,largedatavolumes,andlargegeographicareas,coordinatinglargenumbersoftransportationelements.Itisspecificallydesignedforafutureofconnectedvehiclesandinfrastructurewiththedatavolumesandprocessingrequirementsthatwillbepresentinthatfuture.

Todothis,thesystemmakesuseoftwokeydesignelements:

• Amicroservicesarchitecture• Cloudtechnologyanddesign(specificallyAmazonWebServices)

Thesetwokeydesignelementsarespecificallydesignedtobeveryresponsivetobothimmediateandlongtermdemandsonthesystem.Theyprovideaveryagilesystemthatcanscaleondemandtoreacttoincreasesindemandforprocessing,suchasrespondingtomultipletrafficincidentsrequiringhighdemandsontheConnectedCorridorspredictivemodelingcomponents.Thisagilityalsoprovideslongtermbenefits,allowingthesystemtomoreeasilyscaletoadditionalcorridorsorlargergeographicareasaswellasincreasesindatavolumesthatcanbeexpectedwithnewdatasources,suchasconnectedandautomatedvehicles.Usingmicroservicesandcloudtechnologytogethermeansthatadditionalserverandcomputationalresourcescanbeappliedondemand,withthemicroservicesarchitecturemakingthesoftwareresponsive,andcloudtechnologyprovidingtheresourcestothesoftwaretomakethatpossible.

Asaresult,thisdocumentdoesnotprovideinformationregardingtheinfrastructuredesign(suchasserversordatacenterrequirements).Therearenoon-premisesoftwareorhardwaresystemstospecifyorpurchase.Hardwarespecificationscanbealteredondemandbasedonsystemloadandconfigurationduringsystemoperationandarenotfixedfortheoperatinglifeofthesystem.

Thissectionwillprovidesomebasicinformationandexplanationofthesetwotechnologiesandhowtheyworktogethertoprovidesignificantbenefitstotheprogram.Thisisprovidedtoassistinunderstandingtheremainingsectionsofthisdocumentandthedesignchoicesmadeinthissystemarchitecture.


6

2.1. MICROSERVICESDEFINITION

Microservicesisatermthatisusedtodescribemanydifferentdesigns,butingeneral,allmicroservicearchitectureshavethefollowingelementsincommon:

• Self-contained,autonomoussoftwarecomponentsthateachprovideaspecificserviceorfunction(independentservices)

• Looselycouplingofasuiteofsuchservicestoprovideoneormoresystemcapabilities• Welldefined,lightweightcommunications(APIs)betweenservicesovernetworkconnections

IntheICMsystem,thisistheprimaryarchitecturalpatternwithinthedatahubandDSS,andthecommunicationsbetweentheDSS,datahub,andCMSarealsopatternedonthisdesign.Thisarchitecturalpatternisoftencoupledwithautomateddeployment,configuration,security,andmonitoringcapabilities.

InboththeDSSanddatahub,thesystemisbuiltwithindividualservices,eachdeployedseparately.Eachservicehasaveryspecificresponsibilitywithinthesystem.Theindividualservicesareconnectedusingoneormoremessagingsystems(KafkaorActiveMQ).Thecommunicationbetweenthoseservicesisdefinedbyacontract,generallytheTransportationManagementDataDictionary(TMDD)withsomemodificationsrequiredtoaddadditionalinformationandensureinterchangeabilitybetweendifferentservices(CMSvendorsandTMCs).

Forexample,thedatahubusesadesignparadigmofadatapipeline.Atypicaldatapipelineforhighvolumedatalooksasfollows:

Reader Processor InterfaceSource Target

PersistenceWorker Database

Figure2-1DataPipelineMicroserviceExample


7

InFigure2-1thesourceingreenistypicallyanexternalTMC,andthetargetinpurpleiseithertheDSSorCMSsystem.Thedatahubcomponentsarethosecomponentsplacedbetweenthesourceandtarget.

Thereader,processor,interface,andpersistenceworkersareallindividualserviceswithaspecific,independenttask.Thelightgreen“pipes”betweentheservicesrepresentthemessagingsystemusedtotransportmessagescontainingdatabetweentheservices.Thecomponenttaskingbreakdownisasfollows:

Table2-1ExampleComponentTasking

Component Task

Source Externalcomponent–notasystemcomponent.Sourceofdataelements.

Reader MaintainSOAPbasedTMDDconversationwithsourcetocollectdata.PlacedatainTMDDstructuredmessageinmessagingsystem.

Processor Collectdatafromprocessingsystemandperformdesiredprocessing.Mayincludequalitychecks,transformation,predictiveanalysisorothertypeofprocessing.

Interface ReceivedatafrommessagingsystemandpresenttoCMSorDSS.Transformdataasnecessaryfortarget.

MessagingSystemPipe

Thedatahubmessagingsystem(ApacheKafka)usedtoprovidecommunicationbetweentheindividualservices.

Target Notadatahubcomponent.TargetmaybeCMSorDSS.

PersistenceWorker

Receivedatafromthemessagingsystem.Savedatainthedatabase.Retrievedatafromthedatabasewhenrequestedandplacedataonthemessagingsystem.

Database Storedata.

ThereadersmaintainaSOAPbasedTMDDconversationwiththesourceandplacethedatareceived,inaTMDDstructuredmessageonamessagetopic(inlightgreen).Theprocessor,receivingthedatamessagesoffofthemessagetopic,doesanytypeofprocessingdesiredsuchasaqualitycheck,transformation,orotherprocess,andplacesitsresultsonanothermessagetopic.Multipleprocessorsmaybeusedinserialorparalleltoprovidethedesiredlevelofgranularityoftheservices.Theinterfaceservicereadstheresultsandprovidesaninterfacewherethetargetcanconnectandreceivetheprocesseddataresults.Aparallelpathfromtheprocessortothepersistenceworkerallowsthepersistenceworkerservicetoalsoreadtheprocessedresultsandstorethoseresultsinadatabase.

Eachofthecomponentsinredareindependent,autonomousservices.Eachhasaspecificfunctionandisindependentoftheotherserviceswithaspecificdesiredinputandaspecificoutput.Bycombiningthesetogetherindifferentconfigurationsviaalightweightmessagingprotocol(loosecoupling)andadefinedAPIsuchasTMDD,aspecificapplicationpurposeisprovided,namelytheprocessing,quality


8

verification,andstorageofdatafromexternalsourcesandmakingthedataavailabletotheCMSandDSS.

2.2. WHYUSEAMICROSERVICESARCHITECTURE

Usingamicroservicesarchitectureprovidesseveraladvantages.Ingeneral,theyprovidehighlevelsofscalability,reliability,resiliencetofailure,parallelization,speedofprocessing,abilitytoadapt,andveryhighdatathroughputcapabilities.

Byseparatingeachofthesystemtasksintoseparateservices,andconnectingthembymessaging,somesignificantbenefitsarerealized.UsingtheexampleinFigure2-1,herearewaysinwhichthesebenefitsarerealized:

Table2-2MicroserviceAdvantageExamples

Advantage MethodofRealization

Scalability Workcanbeparallelizedasloadonthesystemincreases,eitherlocallyorforanentirepipeline.Forexample,ifaspecifictaskrequiressignificantprocessingresources,multipleprocessorscanbeusedinparalleltosharetheprocessingload.Thisprovidessignificantscalabilityadvantages.

Reader Processor Interface

Processor

Processor


9


SpeedofProcessing

Workcanbebranchedtocompleteseparatetasking.Forexample,aprocessorforpredictiveanalysisandasecondprocessorforaqualitycheckcanbesplitintotwoseparatepaths,withindependentprocessorsforeachtask.Thisprovidessignificantspeedofprocessingadvantages.

ReliabilityandResiliency

Failureofasingletaskinstancemayresultindegradedperformanceforasinglepipeline,butwillnotaffectothersystemprocesses.Usingmultipleparallelinstancesofataskcanensurethatevenduringfailure,aprocesscancontinuetofunction.Evenwithasingleinstanceofthetask,therestartofanewinstancewillensurethatthepipelinewillrecoverfromthefailure,usuallywithinminutes.Thisprovidessignificantreliabilityandresiliencyadvantages.

Reader PredictiveAnalysis

QualityCheck

Processor


Processor

Processor


10


AbilitytoAdapt-IncrementalUpgradesandImprovements

Asingleprocesstaskcanbeupgradedorreplacedwithanalternativewithoutaffectingtheothersystemprocesses.Onlytheprocesstobeupgradedorreplacedneedbeaffectedinasystemupgradedeployment.Withproperprocedures,upgradesorreplacementscanbeachievedwithoutinterruptiontosystemoperation.Intheexamplebelow,asourcesystemmaybeupgradedwiththeonlyimpactonthesystembeingthereplacementofthereaderinstance.Thenewreaderinstancecouldbebroughtupwhiletheoldreaderandsourcecontinuestooperate.Whenthenewreaderandsourceareready,theoldreaderisterminatedandthenewreaderisallowedtocommunicatewiththemessagingsystem.Newsystemcapabilitiescanbeaddedsimplybyaddingthenewserviceorservicestotheexistingsystemwithoutchangingthecurrentprocessing.Thisprovidessignificantadvantagesfortheabilitytoprovideincrementalimprovementswithcontinuousoperation.

OldReader

Processor Interface

NewReader

NewSource

OldSource


11


OptimizationandCostEfficiency

Hardwarerequirementscanbetunedtothespecificneedsofeachprocess.Forinstance,apredictiveanalysismayrequiresignificantCPUand/ormemoryrequirements,whereasareaderorinterfacerequiremuchsmallerCPUandmemoryrequirements.IntheICMsystemdesign,sensingdataisprocessedusinganApacheSparkclusterrunningonaclusterofseveralAWSEC2instances.ReadersarerunonmuchsmallerEC2instancesandthedatahubinterfaceisrunonmediumsizedAWSEC2instances.Thehardwareissizedfortheindividualprocessrequirements.Thisprovidessignificantefficiencyandcostadvantages.



12

2.3. USEOFTHECLOUDANDAMAZONWEBSERVICES(AWS)

Usingthecloud,andintheI-210corridor,specificallyAmazonWebServices(AWS),enablesmanyofthecapabilitiesinherentinthemicroservicesarchitecture.ThereareadditionalbenefitstousingAWS,butthissectionwillfocusonthoseservicesandbenefitsthatarespecifictothemicroservicesarchitectureimplementationintheI-210ICMprogram.

PrimaryAWSservicesandcapabilitiesusedtoachievetheadvantagesofamicroservicesarchitecturearedetailedbelow.

Table2-3AWSServiceUsage

AWSService DefinitionandUses

ElasticCloudCompute(EC2)

Amazon’sEC2serviceprovidesresizablecomputecapacityondemand.TheI-210projectusesEC2toprovideserverresourcesforthedifferentserviceswithinthemicroservicesdesign.UsingEC2servicesallows:

Scalability–additionorremovalofEC2resourcesbasedontheloadexperiencedbythesystem

Speedofprocessing–abilitytoparallelizeworkacrossmultipleEC2instancesandsizeEC2instancesaccordingtodemand

Incrementalupgradesandimprovements–abilitytostartandstopEC2instanceswithdifferentversionsofsoftwareandhardwareasneeded

ResilienceandReliability–abilitytoreplacefailedinstancesupondemand

OptimizationandEfficiency–AWSprovidesaselectionofEC2computeinstances,allowingvariationofCPU,memory,storage,andnetworkingoptionsdependinguponsystemneed.


13

AWSService DefinitionandUses

CloudFormation Amazon’sCloudFormationserviceprovidestheabilitytoprovisionandinitializetheI-210systemsenvironment,includingnetworking,security,EC2,databases,virtualprivatecloud(VPC),andotherenvironmentresources.Thisserviceiskeyto:

Scalability–Cloudformationisusedtoensureresourcesarebroughtupinaconsistentmanner,ensuringconfigurationmanagement,security,andconsistentconfiguration.

Incrementalupgradesandimprovements–CloudFormationisusedtomanageandexectutethedeploymentofupgradesandimprovements.

ResilienceandReliability–CloudFormationisusedtoensurepropersystemconfigurationmanagementandreliable,repeatabledeploymentofsystemcomponents.

OptimizationandEfficiency–CloudFormationprovidesautomateddeploymentcapabilitiesminimizingmanualhumaninterventioninthedeploymentprocess.

Security–CloudFormationallowscompletelyautomateddeploymentofsystemcomponents,minimizinghumanerrorinsystemconfigurationandconsistentmanagementofsystemandsecurityconfiguration.

RelationalDatabaseService(RDS)andElasticMapReduce(EMR)

RDSandEMRaremanagedservicesprovidedbyAWSforthePostgresdatabaseandApacheSpark.Theseservicesminimizethesystemadminstrationrequiredforsystemoperationsandmaintenance.ThespecificapplicationcodeanddatabaseschemasarestilltheresponsibilityoftheI-210program,butthepurchase,deployment,andmanagementoftheunderlyinghardwareandPostgresandSparksoftwareismanagedbyAWS.

2.4. IMPACTONTHEDESIGNDOCUMENT

AsaresultoftheflexibilityofthemicroservicesarchitectureandAWSservices,theHighLevelDesignspecificationmaybedifferentthanwhatistypicalforotherprojectsinvolvingcomplexsoftwareimplementations.Thedesignitselfissignificantlydifferent,requiringbothadescriptionofthedesignpatternsthemselvesaswellastheirimplementation.Additionally,thisdocumentdoesnotprovideinformationregardingtheinfrastructuredesign(suchasserversordatacenterrequirements).Therearenoon-premisesoftwareorhardwaresystemstospecifyorpurchase.Hardwarespecificationscanbe


14

alteredondemandbasedonsystemloadandconfigurationduringsystemoperationandarenotfixedfortheoperatinglifeofthesystem.

TheI-210pilotisaproofofconcept,andtheI-210ICMsystemisdesignedforincrementalchangeandimprovement,withnewcapabilitiesbeingaddedandexistingfunctionsimproved.Itisdesignedsothatthesechangescanoccurduringthepilotperiodandthroughouttheservicelifeofthesystem.Whilethebreakdownandseparationofserviceswillbedefinedinfuturedesigndocuments,itisintendedthatthesebreakdowns,andthewayinwhichtheyareconnectedcanbechangedovertime,resultinginaverydynamicandadaptablesystem.

Thisdocumentfocusesonthesystemandcomponenthighleveldesignsandthehighleveldesignandarchitecturepatternsusedwithinthesystem.


15

3. SYSTEMPRIMARYOBJECTIVESANDPURPOSE

TheoverridingpurposeoftheI-210PilotistoreducecongestionandimprovemobilityalongasectionoftheI-210corridorinLosAngelesCountythroughthecoordinatedmanagementofitsmajornetworks:theI-210freeway,keysurroundingarterials,andlocalandregionaltransitservices.Thegoalistoenableallcorridor“actors”—transportationsystemmanagersandoperators,controlsystems,vehicles,andtravelers—toworktogetherinanefficientandcoordinatedway.

TheseimprovementswillbeachievedbydevelopinganddeployingtheICMsystemdescribedinthishighleveldesigndocument.AttheheartoftheproposedsystemwillbeaDecisionSupportSystem(DSS)designedtohelpcorridorsystemoperatorsmanageincidents,unscheduledevents,andplannedeventsmoreeffectively.Thissystemwilluseinformationgatheredfrommonitoringsystemsandprovidedbypredictiveanalyticaltoolstoestimatecurrentandnear-futureoperationalperformance.Theinformationwillbeusedtodeveloprecommendedcoursesofactiontoaddressproblemscausedbyidentifiedincidentsandevents.Morespecifically,thissystemisexpectedto:

• Improvereal-timemonitoringoftravelconditionswithinthecorridor• Enableoperatorstobettercharacterizetravelpatternswithinthecorridorandacrosssystems• Providepredictivetrafficandsystemperformancecapabilities• Beabletoevaluatealternativesystemmanagementstrategiesandrecommenddesiredcourses

ofactioninresponsetoplannedevents,unscheduledevents,andincidents• Improvedecision-makingbytransportationsystemmanagers• Improvecollaborationamongagenciesoperatingtransportationsystemsinthecorridor• Improvetheutilizationofexistinginfrastructureandsystems• Moreefficientlyusesparecapacitytoaddressnon-recurringcongestion• Reducedelaysandtraveltimesalongfreewaysandarterials• Improvetraveltimereliability• Helpreducethenumberofaccidentsoccurringalongthecorridor• Reducetheperiodduringwhichthecongestionresultingfromanincidentoreventaffects

corridoroperations• Reducegreenhousegasemissions• Generatehighertravelersatisfactionrates• IncreasetheoveralllivabilityofcommunitiesinandaroundtheI-210corridor

WhiledevelopmentoftheproposedsystemisunderthefinancialsponsorshipofCaltransHeadquarters,thesystemwillbedevelopedwithcooperationofthelocaltransportationagenciesthathaveagreedtoparticipateinitsoperation,incoordinationwithPATH.Projectactivitieswillincludethedesign,development,installation,testing,andoperationofvariouscomponentsoftheICMsystem,aswellasthedevelopmentofinterfaceswithexistingmonitoringandcontrolsystems.Forexample,theICMCoreSystemwillbeinterfacedwithtrafficmanagementsystemsownedbyCaltrans,suchastheAdvancedTrafficManagementSystem(ATMS).

Itisimportanttounderstandthatratherthanhavingasystemdeliveredthatmeetsalloftherequirementsinthesystemrequirementsspecificationonitsfirstdayofoperation,thesystemisbeingdevelopedinaniterativefashion,allowinglearningandfeedbackbetweenoperationand


16

design/implementation.Asaresult,thisdesignattemptstoaccommodateallofthevariousrequirementsbyprovidingascalable,flexible,andextendableplatformthatcanaddresstheserequirementsinvariouswaysbasedonthepilot’sexperience.ItisalsoexpectedthatthisapproachwillallowCaltransandlocalagenciestoaddressnewdiscoveriesandideasthatmaybeinformedbyfuturecorridoroperationsandactivities.

3.1. PROJECTGOALSANDOBJECTIVES

TheprimarygoaloftheI-210PilotICMprojectistoimproveoverallcorridorperformancealongasectionoftheI-210corridor.Thistranslatesintothefollowingspecificgoals:

1. Improveoperationalsituationalawareness2. Promotecollaborationamongcorridorstakeholders3. Improveresponsetoincidentsandevents4. Improvetravelreliability5. Improveoverallcorridormobility6. Empowertravelerstomakeinformedtraveldecisions7. Facilitatemulti-modalmovementsacrosstheregion8. Promotetransportationsustainabilitybyreducingimpactsontheenvironment9. Improvecorridorsafety

Foreachofthesegoals,Table3-1furtheridentifiesthemainoperationalobjectives.Manyoftheobjectivesaresimilartothoseoftraditionaltransportationimprovementprojects.Many,however,alsofocusonimplementingmorecomprehensivetravelandsystemstatusmonitoringsystems,improvedoperationalforecasting,improvedinformationdisseminationtotravelers,enhanceddata-sharingcapabilities,demandmanagementapproaches,andimprovedcollaborationamongtransportationsystemoperators.

Table3-1–ICMSystemGoalsandObjectives

Goals Objectives

1.Improvesituationalawareness

• Establishminimumrequirementsfordatacollectiontosupportsystemmanagement• Increasedatacollectionopportunitiesfromarterialsandlocalroads• Improvethecollectionofreal-timeoperationaldatafromnon-traditionalsources,suchasprobevehicles

• Developacomprehensivecorridorinformationaldatabasecoveringallrelevanttravelmodeswithinthecorridor

• Improvethequality,accuracy,andvalidationprocessofcollecteddata• Increasetheabilitytoestimatetraveldemandpatternsinamulti-modalenvironment• Improvetheabilitytoforecastnear-futuretravelconditionsbasedonknownincidents,roadconditions,weather,andlocalevents

• Developperformancemetricsconsideringallavailabletravelmodes

2.Promotecollaborationamongcorridorstakeholders

• Strengthenexistingcommunicationchannelsamongthecorridor’sinstitutionalstakeholders• Exploreopportunitiesfornewcommunicationlinksbetweencorridorstakeholders• Improvecooperationandcollaborationamongcorridorstakeholders• Developregional/jointoperationsconcepts


17

Goals Objectives

• Identifynewmethodsofcollaboration• Extendcorridorperformancemetricstothenetworklevel• Investigatenewtypesofagreementsbetweenparticipatingagencies

3.Improveresponsetoincidentsandunexpectedevents

• Reducethetimeneededtoidentifytheexistenceofanincidentorunexpectedevent• Reducethetimeneededtorespondtoincidentsorunscheduledevents• Enhancethecoordinationofactivitiesamongfirstresponders,trafficmanagementagencies,andtransitagenciestominimizeimpactsonsystemoperations

• Reducethetimeneededtoimplementcontrolactionstoaddresscongestionresultingfromanincidentorevent

• Reducethetimeneededtodisseminaterecommendeddetoursaroundanincidentorevent

4.Improvetravelreliability

• Improvetraveltimepredictabilityalongthecorridor• Reducetheimpactsofincidentsandeventsonnetworkoperations• Improveincident/eventnotificationforfirstrespondersandnetworkoperators• Improveincident/eventnotificationtotravelersandfleetoperators• Providetravelersandcommercialvehicleoperatorsaffectedbyanincidentoreventanenhancedabilitytoseekalternateroutesormodeoftransportation

5.Improveoverallcorridormobility

• Reducedelaysincurredbytravelers• Reducetheimpactsofincidentsandeventsonnetworkoperations• Efficientlyusesparecapacityalongcorridorroadwaystoplannecessarydetoursaroundincidentsorevents

• Promotestrategiestoinducedesirabletraveldemandpatterns• Coordinatethemanagementoffreewayandarterialbottlenecks• Promoteincreasesinvehicleoccupancy• Promoteincreasesintransitridership

6.Empowersystemuserstomakeinformedtraveldecisions

• Improvethedisseminationofreal-time,multi-modaltravelinformation• Enhancetheuseofinfrastructure-basedinformationaldevices(freewayCMS,arterialtrailblazersigns,kiosks,etc.)toprovideen-routeinformationtotravelers

• Enableindividualstoreceivetravelinformationonconnectedmobiledevices• Makearchivedhistoricaldataavailableto511servicesandinformationserviceproviders• Supportthedisseminationoftravelinformationby511servicesandthird-partyproviders

7.Facilitateregionalmulti-modalmovements

• Promotetheintegrationofcommuterrailandbusserviceswithcorridoroperations• Facilitatetransfersacrossmodesduringincidentsandevents• Providerelevantregionaltravelinformationtotravelers• Directtravelerstopark-and-ridefacilitieswithavailablespaces

8.Promotetransportationsustainability

• Reducefuelconsumption• Reducevehicleemissions• Identifyfinanciallysustainablesolutionsforlong-termsystemoperationsandmaintenance• Encouragetheuseoftransit,walking,andbicyclingwhereappropriate• Supportlocallypreferredalternativescompatiblewithcorridorobjectives• Developandimplementperformancemetricsreflectingenvironmentalgoals


18

Goals Objectives

9.Improvecorridorsafety

• Reducecollisionrates• Reducetheseverityofcollisions• Reducethenumberoffatalities• Reducetheimpactsofprimaryandsecondaryincidentsonnetworkoperationsthroughimprovedincidentmanagement

• Improvesafetyforbicycles,pedestrians,andtransit

3.2. TECHNICALCAPABILITIESSOUGHT

Tohelpmanagetravelactivitieswithinthecorridorduringincidents,unscheduledevents,andplannedevents,theprojectisseekingthefollowingtechnicalcapabilitiestosupportthegoalsandobjectivesidentifiedinSection3.1:

• Gatherandarchiveinformationcharacterizingtrafficoperations,transitoperations,andtheoperationalstatusofrelevantcontroldeviceswithintheI-210corridor.

• IdentifyunusualtravelconditionsontheI-210freewayornearbyarterialsbasedonmonitoringdataprovidedbyvarioustraffic,transit,andtravelmonitoringsystems.

• Identifysituationsinwhichanincidentonroadwaysortransitfacilitiessignificantlyaffectstravelconditionswithinthecorridor.

• Providecorridor-wideoperationalevaluationstotrafficmanagers,transitdispatchers,andotherrelevantsystemmanagers,includingprojectedassessmentsofnear-futuresystemoperationsundercurrentandalternatecontrolscenarios.

• Identifyrecommendeddetoursaroundincidentsorroutesleadingtothesiteofanevent,consideringobservedtravelconditionswithinthecorridor.Dependingontheneed,andfinalsystemcapabilities,specificdetoursmayberecommendedformotoristsandtransitvehicles.

• Identifyrecommendedsignaltimingplanstouseatsignalizedintersectionstoimproveand/oraccommodatetrafficflowinfluxduringincidentsandeventsandimproveoverallcorridormobility.

• IdentifyrecommendedrampmeteringratestouseonindividualI-210freewayon-rampsandconnectorstomaintainoverallcorridormobility.

• IdentifymessagestopostonavailablefreewayandarterialCMSstoinformmotoristsofincidentsandevents.

• ProvideguidancetomotoristsontheI-210freewayandsurroundingarterialsusingavailablefreewayCMSs,arterialCMSs,andarterialdynamictrailblazersignsregardingwhichdetourtotaketogoaroundanincidentorwhichroutetofollowtoreachthesiteofanevent.

• Provideinformationtomotoristsabouttheavailabilityofparkingandtransitservicestohelptravelersmakealternatemode-choicedecisions.


19

• Provideuniformtrafficmanagementstrategiesacrossjurisdictionalboundariesduringincidentsandevents.

• Provideinformationtomotoriststhroughthird-partyoutlets,suchas511services,navigationapplicationproviders,etc.


20



21

4. HIGHLEVELDESIGNOBJECTIVES,CONSTRAINTS,ANDPRINCIPLES

Thecoresystemdesignisgovernedbyafewkeyprimarydesignobjectivesdictatedbytheprojectandtherequirements:

• Realtimeoperation–Thesystemmustoperateinanearrealtimeenvironment.Thetimebetweenanincidentoccurringandaresponseplanimplementationisacriticaltimeperiod.Responsetimesshouldbedictatedprimarilybythetimetonotificationandconfirmationoftheincident,andthetimetofullyimplementadecision.Thetimerequiredbythesystemtoprocessinformationshouldbeminimizedsoastohavethemaximumpositiveimpactoncorridoroperations.

• Speedtodecision–Thereisasignificantamountofdataprocessingrequiredtomaintainbothoperatorawarenessandtoensurethemodelingwithinthedecisionsupportsystemisupdatedwiththelatestavailableinformation.Dataprocessinganddecisionprocessingtimeshouldbeminimized.

• Qualityofdecision–Thequalityoftheresponseplansisadirectresultofthetrafficestimationquality,trafficpredictionquality,dataprocessingtime,dataquality,andrulesusedtogenerateresponseplans.

• Abilitytomeasureoutcomes–Theremustbeahighlevelofconfidenceinthesystemoutcomes,andtheseoutcomesmustbecontinuouslymeasuredandmonitoredwithprocessesinplacetoimprovethesystemseffectivenessovertime.

• Incrementaldeployment–Thesystemmustbeabletobedeployedincrementally,addingnewcapabilitiesovertime.

• Systemflexibility–Thesystemmustbebuilttobeflexible,asitisintendedasapilotthatisadjustedandmodifiedasexperienceisgainedwithoperations.Itisintendedthatthesystemwillalsochangeasnewcapabilitiesareadded.Inaddition,thisflexibilitywillbekeytofutureimplementationsinothercorridorswithdifferentintegrationneedsanddifferentrequirements.Itisalsoexpectedthattransportationitselfwillbechangingradicallyoverthelifetimeofthesystem,soflexibilityiskeytoitslongtermviability.

• Secureoperations–Asthesystemhasthecapabilitytorequestchangestotrafficcontrolsacrossalarge,complexurbancorridor,securityofthesystemiscriticaltoitssuccess.

Coresystemdesignislimitedbythefollowingconstraints:

• AbilitytobeoperatedandmaintainedbyCaltranswithoutsignificantlicensingcosts–Thesystemmustbedesignedwithopensourcecomponentsasmuchaspossible.Itisnotdesiredtohavesignificantlicensingcostsrequiredforsubsequentdeploymentsforfuturecorridorsoroverlongperiodsoftime.ItisintendedthatCaltranswillbecapableofdeploying,maintaining,andoperatingthisandfuturedeployments.

• Limitedtimetodeploy–Thedeploymentscheduleisaggressive,creatingtheneedtoensuresignificantreusabilitywithinthedesignsothatmultipledatasourcescanbeincorporatedintothesystemwithoutdesigningnewdatapipelinesforeachone,utilizingacommonsetofdesignpatternsandsystemlibrariesfornewpipelines.


22

• Constraineddevelopmentresources–Caltransprovidedafixedamountoffundingsothesystemdesignmustnotexceedourresourceswithcomplexityandadditionalfeatures.

Thesecoredesignobjectivesandconstraintsareimplementedwiththefollowingdesignprinciples:

• Clouddevelopment,deployment,andoperations–Inordertoachievemaximumflexibilityinbothsystemdevelopmentandfutureconfigurations,minimizeresourceutilizationindevelopmentanddeployment,andminimizedeploymenttime,thecoresystemisdesignedfor100%cloudoperationswithinanAmazonAWScloudenvironment.

• Thesystemisapilotsystemanditexpectedthataswelearnfromthedeploymentofthesystemchangeswillbeneededandrecommended.

• Caltransshallbecapableofsupportingthesystemwithitsinternalresources.• Decisionsproducedintheformofresponseplansshallbebasedoncurrentcorridorinformation

withlimiteddelaysininformationprocessing.• Datamaintainedwithinthecoresystemwillbelimitedtothedatarequiredforsystem

operation.LongtermdatastorageshallbeafunctionofPeMS.• Thesystemwillbedesignedforfuturegrowth,incrementalimprovements,future

transportationsystemchanges,changesintransportationitself,geographicchanges,andnewandupdatedinformationsourcesandneeds.

• Easeofdeployment• Easeofmaintenance• Portabilityofthesystemdesignandcomponentstoothercorridors• Highlydecoupleddesignforflexibility,scalability,redundancy,andreliability• Useavailabledatastandardswheneverpossible• Standardizedexternalinterfacesforeaseofportabilityandinclusionofnewsubsystems• Maintenanceofaseparationofconcernsbetweendatamanagement,decisionsupport,and

controlfunctions.• Designwithstate,regional,andlocaltargetedcomponentsforfuturescalabilityand

standardizeddeploymentacrossthestate.


23

5. CORESYSTEMHIGHLEVELDESIGN

ThecoresystemhighleveldesignisillustratedinFigure5-1.Thishighleveldesignprovidesclearseparationbetweenexternalsystemsprovidingdataandreceivingcontrolrequests(green),thedatahubreceivingandprocessinginformationfromthoseexternalsystems(red),decisionsupportprovidingresponseplansforincidents(blue),andthecorridormanagementsystemprovidinguserinterface,responseplanselectionandapproval,andsendingofcontrolrequeststoexternalsystems(purple).

Figure5-1CoreSystemHighLevelDesign

5.1. MAJORCOMPONENTS

AsshowninFigure5-1,theICMCoreSystemiscomposedofthreemajorsubsystems:theDataHub,theDecisionSupportSystem,andtheCorridorManagementsubsystem.Thesesubsystems,plustheexternalfieldelementstheCoreSysteminteractswith,aresummarizedinthefollowingtable(color-codedtomatchFigure5-1)anddescribedindetailinthefollowingpages.

Table5-1MajorSystemComponents

Component Description

DataHub Providesforreceiptandprocessingofallcorridordataandamethodofcommunicationamongthethreesubsystems,usingacommonsetofdatadefinitions.Providesoperationaldatapersistenceandretrieval.

DecisionSupport Providescurrenttrafficstate,responseplandevelopment,andresponseplanperformancepredictiontoprovideoneormorerecommendedresponseplansforincidentsandevents.

CorridorManagement Providestheprimaryuserinterfaceforsystemoperators,amethodforuserstomonitorcurrentcorridorandcorridorassetstates,interactwiththeDecision


24

SupportSystem,review,evaluate,select,andapproveresponseplans,andinteractwithexternalsystems,particularlyforexecutionandmanagementofresponseplans.

FieldElements Representexternalprovidersandconsumersofinformationandrequestsforactionsuchasintersectionsignals,rampmeters,corridorsensing,andotherelements,usuallythroughrespectivetransportationmanagementsystemsandTMCs.

ThedesignfortheI-210Pilotwillnothavealayeredgeographicapproach,butthedesignisintendedtoallowsuchanapproachinthefuture.Therearethreegeographiclayerstothedesign:state,regional,andlocal.TheintentisthattheDataHuboperatesonaregionallevel(Caltransdistrict),withthepotentialforservingmultiplecorridorswithinaregion.DatawouldbeconsolidatedandaggregatedatastatelevelformultipleregionsviaPeMS,tosupportlargerscalearchiving,businessintelligenceanalysis,andcontinuedimprovementofcorridorandICMsystemcapabilitiesatthestatelevel.TheDecisionSupportandCorridorManagementcomponentsoperateonalocallevel,withinasinglecorridor.Withstateconsolidationofdata,regionaldatacommunication,andlocaldecisionsupportandresponseplanexecution,amethodofsharinginformationbetweencorridorsisenabled,whileensuringlocaljurisdictioncontroloftrafficeventandincidentresponse.

5.2. FIELDELEMENTS

GreenelementsinFigure5-1representthevariouscorridorfielddatasourcesandfieldelementcontrols,includingvariousstate,regional,andlocaltransportationsystems,regionaltransportationdatanetworks,andprivateinformationproviders.

• Ontheleftsideofthediagram,theseelementsrepresentthevariousdatasourcesforinformationconsumedandprocessedbytheICMsystem.

• Ontherightside,theserepresentthevariouscontrolinterfacestoexecuteresponseplanelementsselectedbyoperatorsoftheICMsystem.

ThesystemsthatwillbeprovidingthedatawithintheI-210corridorinclude:

Table5-2–FieldSystems

Source InformationTypePasadenaTMC* PasadenaintersectionsignalsArcadiaTMC* ArcadiaintersectionsignalsCountyTMC-KITS* LACountyintersectionsignals

DuarteintersectionsignalsMonroviaintersectionsignals

CaltransATMS** FreewayvehicledetectionRampmetersDynamicmessagesystem


25

IncidentinformationCaltransLCS* LaneclosuresCaltransTSMSS* IntersectionsignalTrailblazerSystem* DynamicmessagesystemforreroutingRIITS Localvideo

CaltransvideoCalPolyODS Environmentalsensing

TransitHSRLaneClosure* CitylaneclosuresNextBus Goldlinetransit

*Indicatesfieldsystemthatacceptscontrolmessages

**Caltrans’ATMSsystemacceptscontrolmessagesandprovideslimitedICMcoresystemcontrol,includingreview,approval,andterminationofresponseplans

Futurefieldsystemsmayincludeprobedataproviders(GPSlocation/speed),additionaltransitinformation,parkinginformation,andothers.

5.3. DATAHUB

DatafromeachofthefieldsourcesarereceivedbytheICMDataHub,representedinredinFigure5-1.TheprimaryfunctionsoftheDataHubare:

• Receivedatafromfieldelementsviaexistingcorridortrafficmanagementcentersandregionaldatanetworks:VariousdatareceiversreceivedataandprepareitforprocessingbytheICMsystem.Thesereceiversaregenerallyexpectedtobebuiltforthespecificinterfacesdefinedbyeachfielddatasource,bothintransmissionmethod(RESTorSOAPwebservices,socket-basedstreaming,file-based,orothers)andtheintendedinitialpathrequiredforsystemdataprocessing.ThepreferredmethodofinformationtransferforthesystemistheTrafficManagementDataDictionary(TMDD)standarddevelopedbytheInstituteforTrafficEngineers(ITE),currentlyatversion3.03d(withcertainmodifications).

• Processdatareceivedfromfieldelements:Datafromfieldelementsmustbevalidatedforcompletenessanddataqualitypriortousebydownstreamsystemcomponents.Withsuchavarietyofdatasources,oftenforthesametypeoffieldelements,datamustbetransformedintoacommonformatandsetofdatasemantics.Whendataisnotprovidedinastandardizedformatbythesource,theDataHubprocessesthedataintoastandardizedformat,TMDDfortransportationassets,GTFSfortransitinformation,orothersdependinguponthedatabeingreceived.Foralldatareceived,dataistransformedintoacommonsetofdatadefinitionsaswell(suchasasinglenamingstandardforallstreetswithinthecorridor).However,itiscriticaltonotethatthistransformationintoastandardizedformatforprocessingwithinthedatahub,whileitmaintainsthedatastructureswithinTMDD,doesnotgenerallymaintainanXMLdataformat.Internalcommunicationswithinthedatahub(andtheDSS)donotuseSOAPprotocols.


26

ThedatahubandDSSuseJMSprotocolsforinternalcommunicationsandforcommunicationsbetweentheDSSanddatahub,usingeitheranActiveMQorKafkamessagingsystemandJSONmessages.Additionalprocessingisalsocompletedwithinthedatahub,eitherforspecificmetrics,calculatedparameters,orpredictiveanalytics.

• Datamessagingandcommunications:Dataprovidedtodownstreamsystems,aswellasinternalsystemcommand,control,andstatusdata—indeed,alldatawithintheICMsystem—ismadeavailableviaaninternaldatabus.Themethodofdatatransportisviadatamessagingtechnologies,namelyActiveMQJMSmessagingorKafkadatamessagingsystems.Thespecificmessagetechnologyisbasedonthetype,size,frequency,andmessagepersistencerequirementsofthedata,dataproducer,anddataconsumers.Exceptionstothesemethodswithinthedatahubarelimited,andaregenerallyusedforlargeblockbulkdataarchiving/datatransportbetweenpersistencestores.InordertoaccommodatemultipleCMSvendors,andtoprovidecommunicationbetweenthedatahub’sKafkamessagingsystemandtheDSSActiveMQmessagingsystem,anApacheCamelbasedinterfacebetweenthedatahubandtheDSSandCMSsystemsisincludedwithinthedatahub.TheCamelinterfacehastheabilitytoprovideSOAPandRESTbasedservicesasnecessary,andtranslationbetweenmessagingsystems.

• Datapersistence:TheDataHubalsoprovidesdatapersistencecapabilities,allowingforpersistenceofrawandprocesseddata,systemcommand/control/status,andothersysteminformationinacentralrepository.Thisdatapersistenceisbrokenintodifferenttimelayers,includinglivereal-timedata,recentdata(0-90days),aggregateddata,andarchiveddata.ItincludesleveragingstateEDWandBIresourcesasacomponentofthedatapersistencecapabilities,specificallyasthesingledatastorefornon-operationaldata(dataolderthan90days).Sincedatapersistencewithinthedatahubislimitedtooperationaluses,andthearchitectureisbasedonapatternofcoreservicesconnectedbymessaging,multipledatapersistencetechnologiesareutilizedspecifictotheneedsofthesystemandthedatabeingstored.Largecollectionsoftimeseriesdata,suchassensordata,isstoredinaCassandradatabase;largerelationalstructureswithsmallerupdatefrequenciesarestoredwithinaPostgresdatabase,andMongoDBisusedwithindatatranslationpipelineswhenmultiplesourcesprovidethesametypeofinformationindifferingformatsandimplementations.NOTE:MongoDBmaybeusedindevelopmentandearlyversionsofthesysteminsteadofPostgresfortherelationaldatastoresinordertoaccommodatecostandscheduleconstraints.

• OrchestrationofservicesandworkflowsbetweenthethreeprimaryICMsystems:ThethreeprimaryICMsub-systems,datahub,CMS,andDSS,whiletheyareindependentlyoperatingsystems,mustcoordinateactionsbetweenthethreeinordertooperateasrequired.Inaddition,allcommunicationbetweenthethreesystemspassesthroughthedatahub.ThisisdonetoprovideastandardinterfaceandinterchangeabilityofDSSandCMScomponentsforfuturecorridors.Todothis,thedatahubprovidestheabilitytomanageworkflows,bothfororchestrationofitsowndatapipelinesandservices,butalsobetweenDSSandCMSsystems.

Anexampleofthisorchestrationisrespondingtoanincident.ConsideraworkflowwhereaCMSsysteminformsthesystem,viaauserinitiatedeventintheCMS,ofaconfirmedincident.ThedatahubreceivesthatincidentandbeginsmanagementofserviceswithinthedatahubandbetweentheDSSandCMS.Firstitensuresthattherequireddatapipelinesareupandrunning,


27

startsthemifnecessary,andensurespersistenceofalldatabeingcapturedduringthetimeperiodoftheincident.Second,itinformstheDSSoftheincidentandrequestsaresponseplan.ItalsoinformstheCMSofthestatusoftheincidentworkflowasitprogresses.WhentheDSSrespondswiththeneedforaresponseplan,theresponseplans,andtheresultsofevaluationandselectionofresponseplans,thedatahubensuresthisdataiscapturedandstored,andforwardstheselectedresponseplantotheCMSwithitsevaluationandranking.IftheresponseplanisrejectedbytheCMS,thedatahubstoresthatresultandforwardsthenextresponseplan(ifanotherresponseplanissuitable–rankshighenoughaboveado-nothingresponseplan).Ifthatresponseplanisselected,itthenisprovidedthatinformationfromtheCMSandstoresit.ThenthedatahubcontinuestheworkfloweitherwithupdatesbasedonnewinformationregardingtheincidentreceivedfromtheCMS,orbasedonaperiodicevaluationbasedonparametersgoverningtheincidenceresponseworkflowwithinthedatahub.

5.4. DECISIONSUPPORT

TheDecisionSupportSystem,portrayedinblueinFigure5-1,providesthefollowingcapabilities:

• Corridortrafficstatedetermination:TheDecisionSupportSystemprovidescorridortrafficstateestimation,providingbothgeospatialtrafficstateinformationandtrafficstatemetrics.Separatearterialandfreewaytrafficmodelsareusedandmergedtoprovidefullcorridortrafficstateatalltimes.

• Corridortrafficstateprediction:TheDecisionSupportSystemprovidescorridortrafficstatepredictionsforusebycorridoroperatorsandforpredictionofincidentandeventresponseplanperformance.Acommercialsimulationengine(TSSAimsun)isusedtoprovidetrafficpredictions.Trafficpredictionsaregeneratedwithaninitialstateincorporatingtheestimatedtrafficstateaswellasthecurrentstateofcorridorassetsfromthedatahub.

• Responseplandevelopmentandevaluation:TheDecisionSupportSystem,uponnotificationofaconfirmedincident,willusearules-basedapproachalongwithtrafficstateestimationandpredictioncapabilitiestodevelop,evaluate,andrankresponseplansforusebycorridoroperators.

5.5. CORRIDORMANAGEMENT

TheCorridorManagementsubsystem,portrayedinpurpleinFigure5-1,shallprovidethefollowingprimarycapabilities:

• Presentationofcorridorstate:Displayofcorridorstate,includingcorridorassets(signals,ramps,cameras,dynamicmessaging,transit,etc.),estimatedtrafficstate,trafficvisualization(cameraoutput),humanassets,andphysicalassets(vehicles,responsecrews).Assetstateincludescurrentoperationalcapabilities,currentoperatingstate,currentfunctionalstate(operating,failed,degradedstates),timeavailability,controllability,etc.


28

• Controlofcorridorassets:TheCorridorManagementsubsystemprovidesthecapabilitytocontrolcorridorassets,takingresponseplansapprovedforexecutionandexecutingeachoftheindividualresponseplanelementsbysendingcommandstotheappropriatestate,regional,andlocalsystemsandentities.TheCorridorManagementsubsystemdoesnotdirectlycontrolcorridorassets,butonlysendscommandstothestate,regional,orlocalsystemsthatdirectlycommandcorridorassets.

• Presentationofresponseplans:TheCorridorManagementsubsystempresentseachresponseplandevelopedbytheDecisionSupportSystem,displayinginmeaningfulwaysthevariousresponseplanelements,howtheywillchangefromthecurrentcorridorstate,howtheychangeduringresponseplanexecution,whatthepredictedoutcomesareforeachresponseplan,whattheactualoutcomesareforaresponseplan,aswellasthevariousmetricsonhowtheresponseplansareevaluatedandtheireffectivenessmeasured.Thispresentationisexpectedtobeinmultiplepresentationformats,includinggeospatial,tabular,comparative,graphical,andothersolution-specificformats.

• Responseplanlifecyclemanagement:Eachresponseplandevelopedbythesystemhasaspecificlifecyclethatincludes:

1. Initiation2. Development3. Evaluation4. Selection5. Approval

6. Execution7. Monitoring8. Close9. Post-incident/eventanalysis

TheCorridorManagementsubsystemprovidesamanagementinterfaceforthislifecycle:

Table5-3ResponsePlanLifecycle

Initiation TheCorridorManagementsubsystempresentsincidentandeventinformationreceivedfromtheDataHubforreview,edit,andconfirmationbythecorridoroperators.

Development TheCorridorManagementsystemprovidesdisplayofstatusinformationreceivedfromtheDecisionSupportSystem(DSS)regardingitsdecisiontodevelopasetofresponseplanstoanincidentorevent,aswellasthedevelopmentofthoseresponseplans.Inaddition,itcansendcommandstotheDecisionSupportSystemtoinitiatespecificDSSfunctions,suchasmockincidentevaluation,orotherfunctionsrequiredfortheICMsystem.

Evaluation TheCorridorManagementsubsystemreceivestheresultsofresponseplanevaluationandtrafficstatepredictionanddisplaysthoseresults,alongwiththeresponseplans,tothecorridoruser.Displayshallincludeindividualplananalysis,aswellasrankingandcomparativeanalysisofresponseplans.

Selection TheCorridorManagementsubsystemprovidestheuserthecapabilitytoselectaspecificresponseplanforsubsequentapprovalandimplementation.


29

Modification TheCorridorManagementsubsystemshallprovideuserstheabilitytomakeminormodificationstoresponseplans.NOTE:Initialversionsofthesoftwarewillnothavethiscapability.

Approval TheCorridorManagementsubsystemprovidesaselectedresponseplantothecorridorstakeholdersatthestate,regional,andlocallevelsforreviewandapprovalorrejection.

Execution TheCorridorManagementsubsystemisthesolecomponentinthesystemcapableofsendingcommandstothevarioussystemsincontrolofcorridorassetsforindividualresponseplancomponentexecution.Itshallhavedisplaysthatallowcontrolandmonitoringofcorridorassetsviathestate,regional,andlocaltrafficmanagementsystemsandassets.

Monitoring Giventhecapabilitytodisplayassetstate,managecorridorassets,andexecuteresponseplanelements,theCorridorManagementsubsystemshallprovideanintegrateddisplayofresponseplanmonitoringoncetheexecutioncommandsaresenttothefieldsystems.Monitoringshallincludedisplayingwhencommandshavebeenexecutedandarecompleteatthefieldassetlevel,alertinguserswhencommandsorassetshavefailed,identifyinganddisplayingvariancesbetweenexpectedandactualtrafficstate,andtheabilitytotakeactionintheeventofresponseplanelementfailureforanyspecificcorridorasset.

Close TheCorridorManagementsubsystemshallbeabletoreturncorridorassetstotheirnormalstateoncetraffichasreturnedtoanormalstate.

Post-incident/eventanalysis

TheCorridorManagementsubsystemshalldisplayacorridorpost-eventanalysisforeachincidentorevent.TheanalysisshallincludeinformationfromtheCorridorManagementsubsystemitself,especiallywithregardtothecorridorassetresponseplanexecution,responseplanexecutionissuesandfailures,trafficanalysis(expectedvs.actual),andothersystemperformancemeasures.Thepost-eventanalysisisprimarilylimitedtoinformationusedbytheICMsystemanditscomponents,aswellasmetricscalculatedpostincident/eventregardingresponseplanandsystemperformance.Itisnotintendedtobeanexhaustiveanalysiswithextensiveadditionalmodelinganalysisand“what-if”scenarios.

• ICMSystemmanagement:TheCorridorManagementsubsystemprovidesmanagementcapabilitiesfortheICMsystem,including:

Table5-4CMSManagementCapabilities

Rulesmanagement TheCorridorManagementsubsystemprovidesauserinterfaceforthemanagementoftherulesusedwithintherulesengine.Thiswillincludetheabilitytocreatebasicrulesandrulesets,editrulesandrulesets,archiverulesandrulesets,provideconfigurationmanagementforrulesandrulesets,makerulesactive,executerulesandrulesets,andimportrulesandrulesets.


30

Generally,rulesthatcanbeeditedwillbesimplerrulesandrulessets,asmorecomplexrulesarelikelytorequireprofessionaldevelopmenteffortandintegration.NOTE:Theinitialimplementationofthesystemwillnotincludethiscapability.

Responseplanmanagement

TheCorridorManagementsubsystemprovidesuserstheabilitytoupdatetheavailableresponseplansandresponseplanelements.Thisincludesadding,archiving,updating,andactivationordeactivationofresponseplansorresponseplanelementsforusewithinthecorridor.NOTE:Theinitialimplementationofthesystemwillincludeonlylimitedresponseplanmanagementcapability.

Systemmonitoring TheCorridorManagementsubsystemprovidesuserstheabilitytomonitortheICMsystemandcomponents.Systemslogs,alerts,statusinformation,controlandexecutionofsystemfunctionsshallbeaccomplishedbytheCorridorManagementsubsystem.NOTE:Theinitialimplementationofthesystemmaynotincludethiscapability.

Security TheCorridorManagementsubsystemprovidesuserauthenticationandauthorizationfortheCorridorManagementsubsystemandallfunctionsavailablewithintheCorridorManagementsubsystemthataffectotherICMsystemfunctions,includingDecisionSupportandtheDataHub.ThisdoesnotincludeuserauthenticationandauthorizationofindividualcomponentssuchasCassandra,Postgres,ormessaging;rather,itprovidestheseservicesforthefunctionsthatusethosecomponents.NOTE:TheinitialimplementationofthesystemwillincludecapabilitieslimitedtosecurityoftheCMSanditsinterface.

Configuration TheCorridorManagementsubsystemprovidesmethodsandinterfaceforallowinguserstochangeanyandallconfigurationelementswithintheICMsystem.Aswithsecurity,thisdoesnotincludeconfigurationofindividualsystemcomponentssuchasCassandraandPostgres,butratherforthefunctionsthatusethesecomponents.NOTE:Theinitialimplementationofthesystemwillhaveminimalcapabilitiesforthisfunction.

5.6. PRIMARYPROCESSFLOW

Figure5-2providestheprimarysystemworkflowillustratingthebasicintegrationbetweeneachofthesubsystems.Whilethisillustrationisnotintendedtocaptureallofthedetailsoftheinteractionsbetweensystems,andtheprocesslifetimesarenotintendedtobeaccuratewithinthissequencediagram,itdoesprovidethebasicsequenceofeventsandprimarycommunicationchannelsfortheprimaryworkflowwithinthesystem,aresponsetoanincidentonthecorridor.Secondaryactionssuchaspersistence,logging,communicationdialogs,andothersarenotdepictedinthisdiagram.Alsonotethat,asdescribedinFigure5-1,allcommunicationbetweentheDSSandCMSisviatheDataHub’sdatabus,althoughthespecificsofthecommunicationchannelarenotillustratedinFigure5-2.


31

Figure5-2PrimarySystemIncidentFlow(Subsystem)

Thebasicworkflowdescribedinthisdiagramisasfollows:

• Anincidentoccurswithinthecorridor.Thediagramshowstheincidentinformationbeingprocessedthroughthedatahub.

• TheincidentisconfirmedbyanoperatorwithintheCMSorCaltran’sATMS.Theinitialpilotsystemwillalwaysuseanoperatortoconfirmanincidentandtheprocesswillbestartedfromthisconfirmation.

• TheincidentinformationispassedtotheDSS’sresponseplandevelopmentcomponent.• Theresponseplandevelopmentcomponentrequestsapredictionoftheimpactoftheincident

onthecorridor.• Thepredictionengineusesthecurrentestimatedtrafficstateandcorridorassetstateto

initializeandrunapredictionwithnoresponseplanexecution(“donothing”prediction).• Theresponseplandevelopmentcomponentusesthe“donothing”predictionandtherules

enginetodetermineifaresponseplanshouldbedeveloped.Iftheresultisnoresponseplanshouldbedeveloped,executionoftheworkflowwouldendwithnotificationtotheCMSofthatresult.

• Iftheresultisthataresponseplanshouldbedeveloped,theresponseplandevelopmentcomponentagainusestherulesengine,resultsofthe“do-nothing”prediction,currentcorridor


32

state,andasetoffixedresponseplancomponentstodevelopalimitednumberofresponseplansforevaluation.Itsubmitsthoseresponseplanstothepredictionengine.

• Thepredictionenginerunsapredictionforeachresponseplan,alongwithanother“donothing”prediction”basedoncurrentcorridorconditions.Itprovidestheresultsofthosepredictionstotheresponseplandevelopmentcomponent.

• Theresponseplandevelopmentcomponentusestheresultsofeachprediction,currentcorridorstate,andtherulesenginetoevaluate,rank,andselectaresponseplantorecommend.

• TheresultsoftheresponseplanpredictionsandevaluationisprovidedtotheCMSforoperatorselection.

• TheCMSprovidestheresultstoanoperator,whoselectstheresponseplantobeimplementedandobtainsapprovalfortheresponseplanimplementation.

• Iftheresponseplanisapproved,theCMSexecutestheresponseplanbysubmittingC2CcommandstotheTMCsandothersystemsrequiredtoexecutecommandstoindividualcorridorassets.

• TheindividualTMCsandothersystemsexecutingtheresponseplancommandsreportthesuccessorfailuretoexecutethedesiredresponseplanelements,andcontinuetoreportcorridorassetstate.

Uponcompletionofthisprimaryworkflow,furtherprocessesinvolvedinresponseplanlifecyclemanagementwilloccur,suchasresponseplanevaluation,responseplangenerationtoadjusttocurrentconditions,responseplancancellation,andresponseplancloseout.


33

6. DATAHUBDESIGN

Thedatahubhassixprimaryroleswithinthesystem:

1. Receiveinformationfromexternalprovidersofthecorridorstate.2. Processinformationreceivedfromprovidersofthecorridorstate,evaluatingthedatafor

quality,providingcommonmetricsandanalysisofthedatareceived,conductingpredictiveanalyticstosupportestimationandpredictionwithintheDSS,andstandardizingtheformatandcontentfordownstreamconsumptionbytheDSSandCMSsystems.

3. Persistinformationreceived,resultsofprocessing,andoverallsystemstateandcommandinformation.Persistoperationallyrequiredinformationlocallyandsendtoarchiveolderinformationforlongertermstorage.Retrieveinformationstoredupondemand(operationaldataforimmediateretrieval,archiveddataforlater,scheduledretrieval).

4. Secureinformationreceived,processedandstored.5. ProvidedatacommunicationsbetweentheprimarysystemsoftheICMcoresystem.6. OrchestrationofservicesbetweentheDSSandCMS.

Inordertofulfilltheseroles,thedatahubprovidesaseriesofdatapipelinestoreceiveinformation,processtheinformation,persisttheinformation,andsecuretheinformation.ThepipelinesuseKafkaandActiveMQmessagingsystemstotransmitinformationthatcanbetappedbypersistenceworkerstopersistinformationtothevariousdatastoreswithinthedatahub,andretrievetheinformationandplacetheinformationbackonthemessagingsystemsfordownstreamconsumption.Externalinterfaces,usingApacheCamel,provideinformationandcommunicationbetweenthedatahub,theDSS,andCMSsystems.Thedatahubcommandgateway,consistingofNetflixConductor,coupledwithCamel,providesorchestrationandworkflowservicesfordatahubprocessesaswellasCMS,datahub,andDSSoperations.


34

Figure6-1DataHubHighLevelDesign

Thisdesignconsistsofindividualservicesconnectedviamessaging.Itisahighlydecoupleddesignbasedonagroupofindependentservicesconnectedbytwomessagingplatforms.Figure6-1providesageneralizeddiagramthatillustratesthreebasictypesofdatapipelines.Sensordataisgenerallyahighfrequency,largerdatavolumepipelinethathandlesalargernumberofsmallermessages.Theheterogeneousdatapipelinetypehandleslargersizedmessagesatlowermessageprocessingfrequencies.Heterogeneousdataischaracterizedbymultiplesourcesprovidingthesametypeofdatainvaryingdegreesofformatandcontentdifferences.Thehomogeneousdatapipelinesaresimilartotheheterogeneousdatapipelines,butgenerallyarebuiltforasingledatasourcethatprovidesallofaspecifictypeofdata.

Adescriptionofthedifferenttypesofcomponentsisprovidedbelow:

Reader–Readersarethebeginningofthedatapipeline.Theirroleissimple–toconnectandgatherthedatafromadatasourceusingtheprotocolandformatnativetothatdatasource,andtoplacetheinformationwithinadatamessagingchannelfordownstreamprocessing.Ingeneral,itdoeslittleornoprocessingofthedata,withanyprocessinggenerallylimitedtosimpleparsingoflargebatchesintoindividualmessages.

Spark–SparkisanApacheSparkclusterthatprovideshighspeed,highvolume,real-timedataprocessingforsensordata.Itsroleistoprovidedatatransformation,dataquality,dataprocessing,and


35

predictiveanalyticsforsensordata.Itreceivesdatafromreaders,processesthatdata,andplacesthedataintoKafkamessagetopicsforusebydownstreamprocesses.

Cassandra–CassandraisanApacheCassandraclusterthatprovidesstoragefortimeseriesdata,primarilysensingdata.Cassandraprovideshighspeed,highvolume,clusteredstorageforsensingdata.Thisdataislimitedtooperationaldatastorageandisnotintendedasalong-termdatastore.

MongoDB(Persist)–MongoDB(Persist)isaninstanceofMongoDBdedicatedforpersistenceofthemorecomplexrelationaldata,suchasintersectionsignalplans,rampmeterplans,roadnetworks,assetinventories,andorganizationalinformation.Itisanoperationaldatastoreandnotintendedasalongtermdatastore.Itisexpectedthatlong-term,thisinstanceofMongoDBwouldbereplacedwithPostgres,anopensourcerelationaldatabase.

Persistenceworkers–PersistenceworkersprovidebothstorageandretrievalservicesforbothMongoDBandCassandradatastores(and,inthefuture,Postgres).PersistenceworkerslistentoassignedmessagechannelsinbothKafkaandActiveMQ,andstoretheinformationintheappropriatedatastore.Requestscanbesenttoapersistenceworkerviaacommandmessagechanneltoretrievedataandplacethatdataonaspecifiedmessagechannelforreplaypurposes.

Processors–Processorsareusedinthehomogeneousandheterogeneousdatapipelinestoprocessdatareceivedfromthevariousdatasources.Processorsprovidedatatransformation,qualityverification,anddataprocessingservicesfordatareceivedfromthesesources.

MongoDB(Transform)–MongoDB(Transform)isaninstanceofaMongoDBdatabaseandisusedtotransformdatareceivedonaheterogeneousdatapipeline.ReadersstorethedatareceivedfromasourceintoMongoDB.ProcessorsthenqueryMongofortheinformationrequiredforprocessinganddownstreamprocessesincludingdecisionsupportandcorridormanagementsystems.MongoDBprovidesanidealplatformforstoringinformationretrievedinanativeformatandfastqueryingofthisinformationwithminimalmaintenancerequiredwhenthesourceformatischanged.

Datahubcommandgateway(DHcommandgateway)–Thedatahubcommandgatewayprovidesroutingandmanagementofcontrolandstatusmessagesforthedatahubalongwiththeabilitytodefineandmanageworkflowsthatgoverncommunicationsandprocesses.ItsroleistoreceivemessagesroutedfromtheinterfacesfortheDSSandCMS,aswellasinternaldatahubcontrolandstatuschannels,provideconfigurableworkflowprocesses,anddynamicallyroutecommandmessagestotheappropriatechannelsforthereceivingprocess.Thisprovidesencapsulationofindividualservicesandensuresthatnewservices,servicechanges,andmessagesystemmodificationscanbeaccomplishedwithoutimpactingothersystems,andiskeytothedecouplingofthesystemservicesfortheentireICMsystem.ThisgatewayusesanimplementationofApacheCamelandNetflixConductor.

Externalinterface/Datagateway–Theexternalinterface/datagatewayencapsulatesthefunctionsofthedatahub,providingasortofswitchboardforusebytheCMSandDSSsystems.CMSandDSSsystemsarenotrequiredtoknowtheinternalsofthedatahub.Insteadtheybothrelyontheexternalinterface/datagatewaytoprovidecommunicationserviceswiththedatahub.Thisexternalinterface/datagatewayusesApacheCameltoprovidebothroutingandtranslationservices.Internaldatahubmessages(KafkaorActiveMQ)aretranslatedintotheActiveMQorSOAPprotocolsusedbythe


36

CMSandDSS.CommonTMDDandGTFSmessageformatsareusedinmostcommunications,sonotranslationofdataformatsisrequiredbythegateway.

PeMS–PeMSisaCaliforniastatesystemthatcurrentlyprovidesstatetransportationdataservices.PeMSwillprovidelongtermstorageforsystemdata,andreportingservicesfornon-realtimedataandreportingneeds.

S3andGlacier–S3andGlacierareAWSstorageservices.ThesetwoserviceswillbeusedtoprovidelongtermdataarchivingforthepurposeofretrievinginformationforreplayoranalysiswithintheICMsystem.TheyarenotintendedaslongtermstorageforPeMSrelatedservices.

NOTES:

DatahubloggingisprovidedviaacommoninstanceofGraylogsharedwiththeDSS.Graylogcollectsandindexesalllogsforeachindividualcomponentwithinthedatahub,andcapturescontrolandworkflowstatuslogmessages.Itsroleistocapturesystemstateanderrormessagesformonitoringandtroubleshootingneeds.ThiswillincludedataexceptionsfordatanotreceivedorreceivedlatefromeachofthedatasourcesfortheICMsystem.

6.1. DATASOURCES

ThefollowingdatasourceshavebeendefinedfortheI-210ICMproject:

Table6-1ICMDataSources

Source InformationType

System Vendor Product C2CTMDD

Pasadena Intersectionsignal

PasadenaTMC

McCain Transparity Planned

Duarte Intersectionsignal

CountyTMC-KITS

KimleyHorn

KITS Planned

Monrovia Intersectionsignal

CountyTMC-KITS

KimleyHorn

KITS Planned

Arcadia Intersectionsignal

ArcadiaTMC

Transcore Transuite Planned

CaltransFWTraffic Vehicledetection

CaltransATMS

Parsons Custom Planned

CaltransFWRamps Rampmeters CaltransATMS



37

CaltransFWCMS DMS CaltransATMS


CorridorTrailblazer DMS Notyetidentified

Custom Planned

CaltransIntersections

Intersectionsignal

TSMSS Transcore Transuite Planned

Traveltimesensing1

Traveltime Vendor Iteris Unknown

Traveltimesensing2

Traveltime CountyTMC

Unknown

Environmentalsensing

Environmental CalPoly ODS Unknown

RIITSTransit Transit CalPoly ODS No

RIITSVideo* VideoMetadata

RIITS Unknown

CaltransVideo* VideoMetadata

viaRIITS Unknown

CaltransFWLaneclosure

Lanestatus LCS Planned

CityLaneclosure Lanestatus StateHSRsystem

StateofCA

Custom Planned

LACounty Intersectionsignal

CountyTMC-KITS

KimleyHorn

KITS Planned

CHPCAD Incident CAD manualinputbyoperator

Caltransincident Incident CaltransATMS


Goldlinetransit Transit NextBus NextBus No

*Videoisnotpassedthroughorstoredwithinthedatahub.

*Videoisnotpassedthroughorstoredwithinthedatahub.


38

6.2. DATAPIPELINES

6.2.1. SENSINGDATAPIPELINE

ThesensingdatapipelinedesignisprovidedinFigure6-2.Inthisillustration,thedifferentsensorfeedscanbeseenontheleft.Thisillustrationshowsthereaderreceivingdatafromadatasource,placingthatdataonaKafkatopic,SparkconsumingthatdataandprocessingthedatautilizingtheMLLibandStreamingSparklibraries,andthenplacingtheprocesseddataonaKafkatopic.DecisionSupportandCorridorManagementsystemscanaccessthatprocesseddatadirectlyviathedatahubdatainterfaces.SparkalsostoresresultsontheCassandracluster.Persistenceworkerscanbeusedtoretrieveprocesseddatawhenrequested,anddatathatisstoredinPostgres,suchassensorinventories,isavailabletoSparkifneededforprocessingthatmayrequiresuchdata.

Figure6-2SensingDataPipelineDesign

ThedatasourceslistedinSection6.1thatwillbeprocessedusingthistypeofpipelineinclude:

Table6-2SensingPipelineDataSources

Source InformationType

System DataType C2CTMDD

Pasadena Intersectionsignal

PasadenaTMC

Vehicledetection

Planned

Duarte Intersectionsignal

CountyKITS Vehicledetection

Planned

Monrovia Intersectionsignal


Planned

StreamReader

FreewaySensors

Probes

Kafka Spark

MLlib

Streaming

Kafka

Cassandra

DecisionSupport

CorridorMonitoring/Control

IntersectionSignal/ArterialSensors

PersistenceWorker

Postgres/PostGIS

StreamReader

FreewaySensors

Probes

Kafka Spark

MLlib

Streaming

Kafka

Cassandra

DecisionSupport


IntersectionSignal/ArterialSensors

PersistenceWorker

Postgres/PostGIS


39

Arcadia Intersectionsignal

ArcadiaTMC Vehicledetection

Planned

CaltransFWTraffic FWTraffic CaltransATMS

Vehicledetection

Planned

CaltransFWRamps Rampmeters CaltransATMS

Vehicledetection

Planned

CaltransIntersections Intersectionsignal

TSMSS Vehicledetection

Planned

Traveltimesensing1 Traveltime Vendor Traveltime Unknown

Traveltimesensing2 Traveltime CountyTMC Traveltime Unknown

RIITSEnvironmentalsensing

Environmental EnvironmentalSensing

RIITSTransit Transit Transitlocation(future)

LACounty Intersectionsignal


Planned

Goldlinetransit Transit NextBus Transitlocation(future)

6.2.2. HETEROGENEOUSDATAPIPELINE

TheheterogeneousdatapipelinedesignisprovidedinFigure6-3.Inthisillustration,thedifferentintersectionsignalfeedscanbeseenontheleft.

ThisillustrationshowsthereaderreceivingdatafromadatasourceandinsertingthatdatainarawmessageformatintoMongoDB.Thereaderretrievesdatafromthedatasourceusingthedatasource’snativeprotocolsandformats.ThepreferredcommunicationstandardisTMDD,usingaSOAPprotocol,


40

usingeitherarequest/receiveorsubscriptionmethod.ThereadertransformsthemessagefromaSOAP/XMLformattoaJSONformatpriortoinsertingintoMongo.

Amessageissentfromthereadertotheprocessortoinformtheprocessoroftheavailabilityofnewdata(notshowninthediagram).

TheprocessorthenqueriesMongotoobtainadesireddocumentwiththespecificattributesrequiredtomakeaTMDDmessagecontainingastandardizedsetofinformationrequiredfordownstreamprocessing.Theprocessoralsoutilizesastandarddictionaryofdatavaluessothatdatafromdifferentsourcesthatmaybedifferentwhenreceived,butthatrepresentthesamevalue,arestandardizedfordownstreamconsumption.Forexample,ifonesourceabbreviatesboulevardasBlvd,andaseconddoesnotabbreviatetheword,theprocessorwillstandardizetoasingleformthatcanbeunderstoodbythedownstreamprocesses.Theprocessoralsoconductsdataqualitychecksandanyotherprocessingrequired.

OncetheTMDDtransformation,qualitychecks,andanyprocessingiscompleted,theprocessorconstructsthefinalTMDDstructuredJSONmessageandplacesitontheoutgoingKafkatopic.Persistenceworkerslisteningtothetopicpersisttheinformationforlateranalysisorreplay.TheCMSandDSSsystemsreceivethemessagefromthedatagateway.

Figure6-3HeterogeneousDataPipeline

6.2.3. HOMOGENOUSDATAPIPELINE

ThehomogenousdatapipelinedesignisprovidedinFigure6-4.Inthisillustration,arampmeterinventoryandstatesourceisusedastheexamplefeedontheleft.Thehomogenousdatapipelineisidenticaltotheheterogeneousdatapipelinewithonlyonedifference.Homogenousdatapipelinesareusedwhenthereisonlyasingledatasourceforthetypeofinformationbeingprocessed.Whenthisoccurs,thereisnoneedtostorethedocumentsreceivedina“schema-less”MongoDBdatabase,since

ActiveMQ/Kafka

ActiveMQ/Kafka

IntersectionSignalReader

IntersectionSignalInventory/State

Postgres/PostGIS

DecisionSupport


Mongo

IntersectionSignal

Processor

PersistenceWorker

PersistenceWorker


41

therearenotmultipledatastandardsandimplementationstoaccommodate.Becauseofthis,thehomogenousdatapipelinedoesnotuseMongoDBinthepipeline,andthereaderandprocessordirectlycommunicateforanydatatransformation,qualitychecks,orprocessingrequired.

Figure6-4HomogenousDataPipeline

6.2.4. PIPELINECONTROL

Allpipelines,regardlessofpipelinetype,areprovidedwiththesamebasecontrolset.Thecontrolsavailableforeachpipelineinclude:

1. Startpipelineprocessing2. Stoppipelineprocessing3. Pipelinestatus4. Replaydata

AllexternalpipelinecontrolrequestsarehandledbythedatahubcommandgatewayandroutedviaActiveMQmessaging.Requestsreceivedbythegatewayareroutedtoanappropriateendpoint.Figure6-5providesaversionofFigure6-1withthecontrolelementsandpathwaysforpipelinecontrolemphasized.

ActiveMQ/Kafka

ActiveMQ/Kafka

RampMeterReaderRampMeterInventory/State

Postgres/PostGIS

DecisionSupport


RampMeterProcessor

PersistenceWorker

PersistenceWorker


42

Figure6-5PipelinePrimaryControlLayer

6.2.4.1. StartPipelineProcessing

Thestartpipelineprocessingrequestwillberoutedviathedatahubcommandgatewaytotheappropriatereaderwithinapipeline.Therequestwillresultinthesepossibleoutcomes:

1. Ifthepipelineiscurrentlynotstarted,thereaderwillbeginreadingdataandinsertingitintothepipeline.

2. Ifthepipelineisalreadystarted,anerrorwillbereturnedfromthecommandgatewayindicatingtheprocessisalreadystarted.

3. Ifthepipelinecannotbestartedforanyreason,anerrorwillbereturnedfromthedatahubcommandgateway.

6.2.4.2. StopPipelineProcessing

Thestoppipelineprocessingrequestwillberoutedviathedatahubcommandgatewaytotheappropriatereaderwithinapipeline.Therequestwillresultinthesepossibleoutcomes:

1. Ifthepipelineiscurrentlyrunning,thereaderwillstopreadingnewdataandwillcompleteinsertionofanydatacurrentlyinprocessintothepipeline.


43

2. Ifthepipelineisnotcurrentlyrunning,anerrorwillbereturnedfromthecommandgatewayindicatingtheprocessisalreadystopped.

3. Ifthepipelinecannotbestoppedforanyreason,anerrorwillbereturnedfromthedatahubcommandgateway.

6.2.4.3. PipelineStatus

ThepipelinestatusrequestisarequestforasubscriptiontopipelinestatusmessagesthatareproducedbytheCommandGateway.

Foreachpipelinestatusrequest,thedatahubcommandgatewaywillprovideachannelforasubscriptiontoanActiveMQtopiccontainingallstatusmessagesforaspecificpipeline.

Thefollowingresponsesarepossiblewhenrequestingapipelinestatus:

1. Aresponsewiththecurrentpipelinestatus.2. Ifthestatusisnotcurrentlyavailable,anerrorwillbereturned.3. Iftherequestisinvalid(suchasthepipelinedoesnotexistorthattherequestisnotproperly

formatted),anerrorwillbereturned.

6.2.5. PIPELINESTATUSANDLOGGING

Allpipelinecomponentsprovideloggingandstatusinformation,regardlessofpipelinetypeorcomponent.LoggingincludestheloggingattheapplicationlevelthatispublishedtotheGrayloginstancesharedwiththeDSS.

Loggingshallbeconfigurableandsetoncomponentstartandlogginglevelsmayincludethefollowing:

1. All2. Debug3. Fatal4. Error5. Warn6. Info

Logginglevelwillbesetuponcomponentinitializationwhenitisstarted.Ingeneral,duringnormaloperation,thefollowinglevelsshallreport–Error,Fatal,andWarn.TheinformationgeneratedbyloggingshallonlybeavailableviaGraylog.

StatusinformationisproducedbythecomponentsandpublishedtoapipelinestatusActiveMQtopic.Thisinformationisavailabletoexternalconsumersviathedatahubdatagateway(usingadatahubstatusrequest)orGraylog.Ataminimum,datapipelinestatusmessagesshallbeprovidedforthefollowing:

1. Pipelineheartbeat–astatusmessageindicatingthepipelineisrunningsentataregularinterval.


44

2. Pipelineerrormessage–astatusmessagesentindicatingthatanerrorhasoccurred.Generally,thiswillincludeFatalorErrorlogmessages.

3. Pipelinewarningmessage–astatusmessagesentprovidingawarningindicatingpotentialissuesinoperation.

Pipelinecomponentsmayincludeotherstatusmessagesasneeded.

6.2.6. CORRIDORMANAGEMENTSYSTEM-DECISIONSUPPORTSYSTEM(CMS-DSS)COMMUNICATIONSPIPELINE

CommunicationbetweentheDecisionSupportSystemandtheCorridorManagementSystemisprovidedviathedatahubandmanagedusingthesamedataandcommunicationpipelinestrategyusedthroughoutthedatahub,providing:

• Trafficestimationresults,includinggeospatialinformationandtrafficmetrics• Trafficprediction,includinggeospatialinformationandtrafficmetrics• Incidentinformation• Responseplansandresponseplanevaluations• DSSStatus• CMSStatus• DSSControl• Trafficestimationandpredictionscenarioinformation

Inaddition,thepipelineprovidespersistencewithinthedatahubofallDSS–CMScommunications.ThepipelinedoesnotincludeanycommunicationstoorfromtheCorridorManagementSystemthatdonotinvolvetheDecisionSupportSystem.

AllCMS-DSSpipelinessupportTMDDcompliantSOAPdialogsinaccordancewiththeConnectedCorridorsDataCommunicationSpecification.SOAPendpointsarepresentedattheDataHubGatewaytosupporttheseconversationsandareexposedtotheCMS.ThedatafortheseSOAPinterfacesareavailablefortheDSSviatheDataHubDataGateway.AllcommandrequestsandresponsesarealsoprovidedfromtheDataHubCommandGatewayforrequiredworkflowmanagementanddatahubcontrolactions.WhileonlytobeprovidedasnecessarytosupportthedifferentCMSvendors,ActiveMQmessagingmayalsobeprovidedasinterfacestotheCMSinsteadofSOAPinterfaces.

AllCMS-DSScommunicationsaremanagedondatahubpipelines.Forfutureuse,datahubsmaysupportmultipleCMSandDSSinstances,soallindividualpipelinesarecreatedforeachCMS/DSSpair.AllmessagesbetweenCMSandDSSinstancesshallbecommunicatedonlythroughpipelinesdesignatedforthatspecificCMS-DSSpairandshallincludethesourceandtargetsystemidentifierswithinthemessages.

CMS-DSSdatapipelineswillgenerallybeinoneofthefollowingbasicconfigurations:


45

Figure6-6DSS-CMSDataPipelineConfigurations

InFigure6-6,twoofmanypossiblecombinationsofdataexchangebetweentheDSSandCMSareillustrated.TheprocessorbasedDSS->CMSdatapipelineillustratedatthetopofthefigureisaconfigurationusedwhentheinformationprovidedbytheDSSrequirestransformationorsomeotherprocessingbeforebeingpassedtotheCMS.Anyprocessingisalwayscompletedwithinaprocessorinthedatahubandisneverdoneinthedatagateway.Thisisdonetoprovidehigherreliabilitytothedatagatewayaswellashigherscalabilityandreliabilitywithintheprocessor.

Thelowerdiagraminthefigureshowsapipelinewithoutanytransformationorprocessing,usedwhentheformattingandcontentofthedatarequiresnotransformationorotherprocessingbeforebeingpassedtotheCMS.ThedatagatewayroutesthedatadirectlytotheCMSfromthereceivingchannelinthedatagatewaywhilealsoroutingthedatatoatopicinthedatahubforpersistencewithinthedatahub.


46

Inbothcases,thecommandgatewaymanagesanyworkflowsrequiredbyeitherpipelineaswellasthepipelinesthemselves.Italsomanagesthedatagateway,dynamicallycreatingthedataroutingwithinthedatagateway.Thisallowsthesystemtobemodifiedwithoutstaticchangestothedatagateway,simplybymodifyingtheworkflowdefinitionswithintheConductorcomponentofthecommandgateway.Newprocessescanbeaddedindependentlyofanyotherprocesseswithinthesystem.

Figure6-8providesanillustrationofapotentialconfigurationoftheCMS–DSSpipeline,anditsassociatedprimarydatatopics,including:

• Incidents• ResponsePlans• DecisionResults• StatusRequest• StatusResponse• EstimationRequest• EstimationMetrics• EstimationResults• EstimationNetwork• EstimationScenario• PredictionRequest• PredictionResult• PredictionMetrics• PredictionNetwork• PredictionScenario

Specificpipelineconfigurationswillbedefinedinthedetaileddesign.Notethatthecommandgatewaycanlistentoanyofthepipelines,allowingevent-basedworkflows.Anexampleofanevent-basedworkflowistheincidentresponseworkflow.Thecommandgateway,listeningtotheeventpipelinethatreceiveseventsfromtheCMS,caninitiatearesponseplanworkflowuponreceivingtheeventmessage.Inthissituation,theincidentreceivedfromtheCMSwillnotberouteddirectlytotheDSS,butrather,itwillbereceivedbythecommandgateway,andthecommandgatewaywillinitiatearesponseplanworkflow.TheworkflowdefinitionwilldefinearesponseplaninitiationrequesttotheDSSthatpassesthroughthedatagatewaytotheDSS,providingtheincidentinformation,aswellasanydynamicroutinginformationorotherworkflowrelatedinformationrequiredbythedatagatewayandDSSinterfacetoprocesstherequestandmanagecommunicationswiththeDSSandCMS.

6.2.6.1. Incident

TheincidentpipelineprovidesconfirmedincidentinformationfromtheCMStotheDSS.ThispipelinemaystartasanActiveMQmessage,orSOAPincidentmessageatthedatagateway.AlsonotethatthispipelinerepresentsaTMDDeventclassdialogsetwithbothrequest/response,andsubscriptions.Subscriptionsarethepreferredmethodofcommunication.TheincidentpipelineincludesanincidentsubscriptionrequesttotheCMS,aswellasthecorrespondingsubscriptionresponses.TheresponsesareprovidedtotheDSSviathedatahubasActiveMQmessages.


47

6.2.6.2. ResponsePlan

TheresponseplanpipelineprovidesresponseplanstotheCMS.AsthereisnoTMDDdialogforresponseplans,thisisaConnectedCorridorscustomcommunication.ResponseplansareprovidedasanActiveMQmessageviatheCMSDataGateway.ResponseplansareprovidedinaccordancewiththeConnectedCorridorsDataSpecification,andincludetheresponseplanelements,event/incidentinformation,andassociatedperformanceindicatorsandmetrics.

6.2.6.3. StatusRequest

ThestatusrequestpipelineisacommunicationchannelforrequestingDSSanddatahubstatus.ItisanActiveMQqueue/message.Requestsmustincludeanidentifierfortherequestingsystem.Aresponsewillincludeanaddressforreceivingstatusmessages.Statusrequestsareessentiallyasubscriptionrequest,withtheresponsesimplyalocationforsubscribingtoacontinuousstreamofstatusmessages.

6.2.6.4. Status

Thestatuspipelineprovidestheresultsfromastatusrequest.

6.2.6.5. EstimationRequest

TheestimationrequestpipelineprovidesamethodfortheCMStorequestanestimation.Ifanestimationiscurrentlyrunning,theresponsetotherequestshallindicatetheaddresswhereestimationresultsarepublished.Iftheestimationisnotcurrentlyrunning,theDSSshallstartanestimationandtheresponseshallincludeamessageindicatingtheDSSisbeginninganestimation,andtheaddresswhereestimationresultsarepublished.

6.2.6.6. EstimationResult

Theestimationresultpipelineprovidestherawresultsofanestimationrequest,includingforfreewaystheestimateddensity,flow,andspeedforeachnetworklinkwithinthefreewayestimationnetwork,andforarterials,theestimateddensityforeachnetworklinkwithinthearterialestimationnetwork.

6.2.6.7. EstimationMetrics

Theestimationmetricspipelineprovidesestimationmetricresults,includingtraveltimeandcurrentdelayestimatesforthefreewayandarterialnetworks.

6.2.6.8. EstimationNetwork

TheestimationnetworkpipelineprovidesthecurrentestimationnetworkinTMDDformat.ThispipelinesupportsTMDDmessaging.


48

6.2.6.9. PredictionRequest

ThepredictionrequestpipelineprovidesamethodfortheCMStorequestaprediction.Theresponsetotherequestshallindicatetheaddresswherepredictionresultsarepublished.Intheinitialversionofthesoftware,predictionsshallonlybeprovidedeitherasaresponsetoanincidentaspartoftheDSSprocess,orshallbeprovidedasareplaytoapreviousprediction.

6.2.6.10. PredictionResult

Thepredictionresultpipelineprovidestherawresultsofapredictionrequest.

6.2.6.11. PredictionMetrics

Thepredictionmetricspipelineprovidespredictionmetricresults,includedtraveltimeandcurrentdelaypredictions.

6.2.6.12. PredictionNetwork

ThepredictionnetworkpipelineprovidesthecurrentpredictionnetworkinaTMDDformat.ThispipelinesupportsTMDDmessaging.

6.2.6.13. CMSCommandStatusPipeline

CommunicationsbetweentheCMSandexternalsystemsorcentersarecapturedbytheDataHub.TheycanalsobeprovidedtothedatahubcommandgatewaysothatthedatahubmayrespondtocommandsissuedbytheCMSsystemtoexternalsystems.

ThisCMSCommandStatuspipelineisasimpleimplementationofanActiveMQtopicthatisprovidedacopyofallCMScommunicationswithanyexternalcenterorsystem.AllsuchcommunicationsareprovidedviaActiveMQmessagecontainingatextrepresentationofanymessagesentorreceived.Messagesarekeyedwiththeexternalsystemorcentercommunicatedwith,aswellaseithersendorreceivetoindicatewhetherthemessagewassenttotheexternalcenterorsystem(send)orreceivedfromtheexternalcenterorsystem(receive)aswellasthetimeofmessagesentorreceipt,asappropriate.

6.3. EXTERNALINTERFACE/DATAGATEWAY

ThedatagatewayprovidesanexternalinterfaceforthedatahubtotheCorridorManagementSystemandtheDecisionSupportSystem.Thepurposeofthisdatagatewayis:

• Providefortwo-waycommunicationbetweentheDataHubandtheDecisionSupportSystem.• Providefortwo-waycommunicationbetweentheDataHubandtheCorridorManagement

System.


49

• ProvideforindirectcommunicationbetweentheDecisionSupportSystemandtheCorridorManagementSystem.

• EncapsulatethefunctionsofthedatahubfromotherICMcomponentsystems.• Provideasecureinterfacetothedatahub.• AllowforthechangefromKafkaorActiveMQprotocolsusedwithinthedatahubtoActiveMQ

messagingorSOAPbasedservicesthatmayberequiredbyotherICMcomponentsystems.• AllowforaswitchboardlikefunctionalitythatcanbeconfiguredfordifferentCorridor

ManagementSystemprovidersorDecisionSupportSystems.• Provideformultipleoutputchannelstopublishinformationtomultipledownstreamconsumers.• Provideevent-timeorprocessing-timebasedorderingofinformationpassedtotheCMSorDSS

(thisisprovidedasaresultofeithermultipleparallelprocessorsbeingusedwithinasingledatastream,multi-threadedprocessingofdatawithinaprocessorinthedatahub,ormultipleKafkapartitionedmessagingmayresultindatamessagesequenceissues).

TheDataHubDataGatewayusesApacheCameltoprovidetheseservices.TwoprimarydesignpatternsareusedasshowninFigure6-7,firstforcommunicationtoexternalActiveMQbrokers,andsecondtoexternalSOAPorRESTwebservicesendpoints.

Figure6-7DataHubDataGateway–ActiveMQandWebServicesDesignPatterns


50

EachofthetwodesignsusesApacheCamelandimplementsaKafkaconsumertoretrievemessagesfromadefinedKafkatopic.Eachalsoprovidesforaprocessorfortransformation,sequencing,androutingofmessages.ForpassingdatausinganActiveMQtopicorqueuehostedbyanexternalbroker,Camel’sSedacomponentisusedforasynchronousmessagingandmessageflowregulation.ForpassingdataviaSOAPorRESTwebservices,anappropriateSOAPorRESTendpointisprovidedforcommunicationwithanexternalSOAPorRESTendpoint.NOTE:AllinternaldatacommunicationswithinthedatahubareconductedviaKafkaorActiveMQdatamessagingandJSONformatting.NativedatacommunicationsareimplementedusingTMDDorotherappropriatestandardformatswhenavailable.WhiletheTMDDorotherstandardsmaynotuseJSONformatting,themessageswithinthedatahubthatcontainthisinformationareJSONformatted,retainingthedatastructuresandrelationshipswithinTMDDorotherapplicablestandard.Whenexternallyexposed,thesedatamessagesareconvertedbacktotheappropriatedataformatdictatedbythestandardused(TMDDorother).

6.4. DATAHUBCOMMANDGATEWAY

Thedatahubcommandgatewayisaninternaldatahubcomponentthatmanagesallcommand,communication,andcoordinationactivitiesofthedatahubandorchestratescommunicationandcontrolofthethreecoreICMsystemcomponents.SincetheDSSandCMSdonotcommunicatedirectly,thedatahuborchestratesworkflowsandcommunicationsbetweenthetwocomponentsandtheinternalcomponentsofthedatahub.Similartothedatahubdatagateway,itusesApacheCameltorouteandprocesscoreICMSystemcommands.Inaddition,itusesaworkflowcomponentdesignedforamicroservicearchitectureusedbyNetflixinitsownproductionenvironmentcalledConductor.Thecommandgatewayprovidesthefollowingcapabilities:

• Receiveallcoresystemrequestsforservices.• Provideexecutionmanagementofallrequestsfordatahubservices.• Provideexecutionmanagementofworkflowprocessingforrequestsinvolvingsimplesinglestep

workflowsorcomplexmulti-stepworkflows.• Persistservicerequestsandtheiroutcomes(successorfailure).• Manageinternaloperationsofthedatahub(starting/stoppingservices,restartonfailure,etc).• OrchestrateactionsbetweentheDSS,CMS,anddatahub.

NOTE:Thedatahubcommandgatewayisaninternaldatahubcomponent.Atnotimearethemessagequeuesandtopicsthatitcommunicateswithdirectlyconnectedtoexternalsystems.Allqueuesandtopicsthatcommunicatewiththiscomponentareinternalqueuesandtopicsconnectedtodatahubcomponentsorthedatahubdatagateway(forcommunicationwithexternalsystems).


51

Figure6-8DataHubCommandGateway

Thedatahubcommandgatewayconsistsofjustafewprimarycomponenttypes.Theseinclude:

• Conductorandrelatedworkflowcomponents• Camelandrelatedroutingandtransformationcomponents• ActiveMQworkflowstatustopic• ActiveMQworkflowtasktopic• Monitor

6.4.1. CONDUCTOR

Conductorisusedfororchestrationoftheindividualpipelinesandbothinternalandexternalrequestsforservices.ConductorisanopensourceprojectdevelopedbyNetflixtomanagesomeofitsownproductionworkflows,particularlywithamicro-servicearchitecture.ThereareanumberofsimilaritiesbetweentheusecasesforwhichConductorisdesignedandtheorchestrationoftheindividualpipelinesandtherequestsforservicesfromtheDSSandCMS,aswellasorchestrationofthecommunicationsbetweenDSSandCMSthatmakeitwellsuitedforuse.

Conductorisusedinan“as-is”configuration“out-of-the-box”.ThedatahubimplementationusestheRESTinterfacesandin-memorydatabasethatcomeswithConductor.NomodificationsaremadetoConductor.Itprovidesworkflowmanagementandcontrol,withworkflowdefinitionsdescribedinJSONformat.


52

6.4.2. CAMEL

ToadaptConductortothedatahubinterfaces,CamelisusedasaninterfacetotheActiveMQandKafkadatahubmessagingservices.CamelprovidestheinterfacebetweenConductor’snativeRESTinterfaceandthedatahub’sActiveMQandKafkadatabuselements.

6.4.3. ACTIVEMQWORKFLOWSTATUSTOPIC

TheActiveMQworkflowstatustopicisusedtoallowindividualdatahubcomponentstoprovideworkflowstatusmessagestoConductor,viatheCamelinterface.Italsoisusedtoprovidegeneralsystemandcomponentstatusinformationforuseinworkflowmanagement.Thedatahubdatagatewayalsoprovidesworkflowandexternalsystemstatus(CMSandDSS)messagesviatheworkflowstatustopic.TheCMSandDSSsystemsareneverrequired(orallowed)todirectlymessageviatheWorkflowstatustopic,butinstead,theircommunicationsaremanagedbythedatahubdatagateway.

6.4.4. ACTIVEMQWORKFLOWTASKTOPIC

TheActiveMQworkflowtasktopicishowworkflowtasksaredispatchedfromConductortotheindividualdatahubcomponents,ortheDSSandCMSsystems(viathedatahubdatagateway).Aswiththeworkflowstatustopic,DSSandCMSsystemsareneverdirectlyallowedtocommunicatewiththeworkflowtasktopic.Instead,thedatahubdatagatewaymanagesthedistributionoftasksandtheresultingresponsesviatheDSSandCMSAPIs.

6.4.5. MONITOR

Themonitorlistenstotheworkflowstatustopicforsystemandcomponentstatusmessages,alwaysprovidingdatahub,DSS,andCMSstateandstatusinformationtotheConductorworkflowmanager.ThisallowsConductortorespondtodegradedsystemstate,eitherbydisablingspecificworkflowsorstartingotherworkflowstorespondtosystemcomponentfailures.


53

7. DECISIONSUPPORTSYSTEMDESIGN

Thedecisionsupportsystem’s(DSS)primaryrolesinclude:

• Provideresponseplansfollowingreceiptofaconfirmedincident.• Evaluateresponseplansandrankthembasedonuserdefinedcriteria.• ProvideoneormorerecommendationstocorridoroperatorsandstakeholdersviatheCorridor

ManagementSystem,whethertoimplementaresponseplanandwhichresponseplantoimplementforeachreceivedconfirmedincident.

• ProvideresponseplanevaluationresultsforcorridoroperatorsreviewviatheCorridorManagementSystem.

• Evaluateimplementedresponseplaneffectivenessandrecommendnewresponseplanswhenappropriate.

TheDSSaccomplishesthiswiththreeprimarycomponents:

• DSSInterface• ResponsePlanManagement• Modeling

TheDSSinterfaceprovidesaninterfaceforsendingandreceivinginformationwiththedatahub,providingroutingandtransformationservicesfortheotherDSScomponents.Theresponseplanmanagementcomponentreceivesincidentinformationandcoordinatesthedevelopmentandevaluationofresponseplans,usingarulesenginethatprovidesconfigurablelogicandrulestocreateresponseplans,evaluateresponseplans,andrankresponseplans.Themodelingcomponentprovidestrafficestimationandpredictioncapabilitiestosupportresponseplancreation,evaluation,andranking.


54

7.1. DSSHIGHLEVELDESIGN

TheDSS’sthreeprimarycomponentsaredescribedinFigure7-1.TheDSSisoneofthethreeprimaryICMsystemsubsystems,andcommunicateswiththeICMsystemviathedatahub’sdatagateway.

Figure7-1DSSArchitecture

AllcorridorinformationisreceivedbytheDSSinterfacefromthedatahubdatagateway.ThemodelingandresponseplanmanagementcomponentsreceiveallcorridordataandsystemstatusviaaseriesofdatachannelsavailablefromtheDSSinterface.

AllcommandstotheDSSandrequestsforDSSstatusarereceivedviaasetofcommandchannelsexposedonthedatahubdatagateway.ThesecommandsareinturnforwardedbytheDSSinterfacetoeitherthemodelingorresponseplanmanagementcomponents.

AllcommunicationswiththeDSSviatheDataHubDataGatewayaremanagedviaActiveMQmessaging.CommunicationsbetweentheDSSinterface,ResponsePlanManagement,andModelingareenabledviaRESTorActiveMQmessaging.TheresponseplanmanagementandrulesenginearetightlycoupledviatheirjavabasedAPIs.

OutputfromtheDSSconsistsprimarilyofresponseplansandtheirevaluationsfromtheresponseplanmanagementsystem,andestimationandpredictionresultsfromthemodelingsystem.


55

7.2. DSSINTERFACE

TheDSSinterfaceprovidesabridgebetweeninformationfromthedatahub’sdatagatewayandtheinternalcomponentsoftheDSS.Figure7-2providesthemethodforpassinginformationbetweenthedatahubandthemodelingandresponseplanmanagementcomponentsoftheDSS.

Figure7-2DSSInterfaceHighLevelDesign

Theprimarydataflowisasfollows:

• DataisplacedonDSSActiveMQtopicsbythedatahubdatagateway.• Dataispulledfromthesetopicsbyprocessorsspecifictothetypeofdataoneachtopic.The

datamayreceiveanydesiredcomputation,aggregation,splitting,qualitychecksorotherprocessingrequiredbytheDSShere.


56

• Thedataispassedtoaconsumer-specifictransformer.ThistransformerpreparesstandardizedTMDDdata(orotherformatwhenTMDDisnotappropriate)fortheconsumer,transformingitintoanyconsumerspecificobjectrequiredfortheconsumer.

• TheprocessedandtransformeddataispassedintoaconsumerspecificActiveMQtopicforusebytheconsumer.

RequestprocessorsprovideroutingofrequestsfromthedatahubtospecificDSScomponentsaswellasprovidinginitialreceiptstatusbacktothedatahubforeachrequest.

Responseplanandestimationtransformerspreparetheresponseplans,predictionresults,andestimationresults,transformingthemfromDSSspecificobjects(modelingobjectsorresponseplanmanagerobjects)toTMDDorotherstandardizedobjects.

7.3. RESPONSEPLANMANAGEMENT

Responseplanmanagementprovidesfunctionsforthedevelopmentandselectionofresponseplans,includingcoordinationoftheactionsoftheresponseplanmanagementandmodelingcomponentsoftheDSS.

Theresponseplanmanagementcomponentrespondstocommandsfromthedatahub,anduponreceipt,orchestratesactionsbetweenitselfandmodelingcomponentstodetermineifaresponseplanmightpositivelyimpacttrafficconditionsandifso,developseveralresponseplans,evaluatethem,andrecommendaresponseplanforimplementation.Theresponseplanmanagementcomponentalsohasalimitedselectionofmethodsimplementedsothatotherspecificrequestscanbemadeviathedatahub.

TheresponseplanmanagementalsomonitorstheDecisionSupportSystemanditscomponents.IthaslimitedcapabilitiestoperformspecificstartupactivitiesrequiredforDSSoperationandmonitorDSScomponentstatus.

Figure7-3ResponsePlanManagementDesign


57

OntheleftoftheresponseplanmanagementcomponentinthefigureisthetransformeddatareceivedfromtheDSSinterface.Thisprovidesassetinformation,routeinformation,andincidentinformationtotheresponseplanmanagementcomponent.Thisinformationismaintainedinalocaldatastore.

Theresponsemanager,uponreceiptofaspecificrequestorincidentmanagesthespecificworkflowsrequiredtorespondtotherequestortoprovidearesponseplanrecommendation.Thisincludesrequestingdecisionsandresultsfromtherulesengine,informationregardingcurrenttrafficstatefromthemodelingsystem,orspecificpredictionsforresponseplansreceivedfromtherulesengine.Theresponseplanmanageralsoassemblesthecompleteresponseplan,andprovidesitasaresponsetosendtothedatahubforstorageanddistributiontotheCMS.

TherulesengineusedwithinresponseplanmanagementisacombinationofjavacomponentsandtheopensourceDroolsrulesengine.Itisdesignedtorespondtoalimitednumberofprimaryquestionsthatcanbeaskedbytheresponseplanmanager.Theselimitedquestionsinclude:

• Doesthecurrentconfirmedincident,withtheresultsofa“do-nothing”prediction,requiredevelopmentandevaluationofresponseplans?

• Whatresponseplansshouldbeevaluated?Createthoseresponseplansfromalimitedsetofresponseplancomponents.

• Whichresponseplan,giventheresponseplansdevelopedandtheirrespectivepredictions,shouldberecommended,listedinarankedorder?

Aflowdiagramillustratesthebasiclogicusedindevelopingresponseplans:


58

Figure7-4ResponsePlanManagerWorkflow

TherulesengineisaJavalibrarythatisincludedintheresponseplanmanagercomponentwithadefinedAPIspecifictoansweringthesedefinedquestions,giventhecurrentstateofthecorridorassets,definedlimitswithinasetofuserspecifiedrules(suchas“donotusethisroutebetweenthehoursof3and5pm”),currenttrafficstate,currenttime,andincidentinformation.

Itisintendedthatthefinaluserinterfacefordeveloping,editing,testing,andevaluatingrulesandtheirperformancewillbeintheCMS.However,initially,thiswillbelimitedandrequireITsupporttoassistwithrulesdevelopmentanduploadingspreadsheetsofrulestoaknownlocation.

7.4. MODELING

Themodelingsystemprovidestwoprimaryservices:trafficstateestimationandtrafficprediction.


59

7.4.1. MODELINGTECHNIQUES

Threetrafficmodelsareusedwithinthemodelingsystem.Theseinclude:

• AcustomfreewaytrafficestimationmodeldevelopedbyUCBerkeleyusingacelltransmissionmodel(CTM).

• AcustomarterialtrafficestimationmodeldevelopedbyUCBerkeleyusinganintersectionqueuemodel.

• AcommercialpredictionmodelusingTSS’sAimsunmodelingsystemandamicro-modelingbehavioralmodel.

Figure7-5-ModelingComponentDesign

Thesystemiscomposedofseveralprimarysubsystems–• Datamanagement(inblue)–receivesandprocessestrafficandtrafficinfrastructuredataso

thatitcanbeconsumedbythemodelingsoftware.• Estimationmodelingsystem(inpink)–buildsandrunsestimations,producesoutputof

estimatedtrafficstate.• Predictionmodelingsystem(inorange)–buildsandrunspredictedtrafficstate,inparticular

predictedresponseplanperformance,includingperformancemetrics.• Calculation/metrics(inlightorange)–consumesestimatedtrafficstateandproducescurrent

trafficandnetworkperformancemeasures.


60

• ProjectManager(inbrown)–providesoverallsystemorchestration,cloudscalingandEC2management,workflow,andexternalRESTinterfaces.Auserinterfaceisavailableforestimationmodeldevelopment.ThisiscurrentlyusedforinternaltestingandQA.

• Persistence–(green/gray)–persiststraffic/trafficinfrastructuredata,modelandmodelbuildingdefinitions,rawandprocessedresults.

CommunicationbetweentheDSSinterfaceandthemodelingsystemisviaaRESTAPIexposedbytheProjectManager.DatafeedsfromthedatahubprovidedataviaActiveMQdatatopics.InternalcomponentcommunicationbetweenmodelingsystemcomponentsisviaActiveMQtopics(data)orqueues(command).

Technologystack:• PrimarycomponentsarebuiltusingJavawiththeSpringframework.Hibernateisusedwith

componentsrequiringPostgresaccess.• PersistenceisbuiltwithJavabasedpersistenceworkers(bothforstoreandretrieveoperations)

andPostgresorCassandraforpersistence.• MessagingviaActiveMQ• ProjectManagerRESTserviceshostedonTomcat• LogManagementviaGraylog• AmazonWebServices,includingthefollowingAWSservices:

o EC2o RDS(Postgres)o S3o VPCo IAMo Otherservicesareusedforcoderepository,build,anddeploymentservices.

Platform/ApplicationServers/OS• MostanyversionofLinuxOSisacceptable,Ubuntuiscurrentlyused• AmazonWebServices• Tomcat

GeneralArchitecturalApproach:

Theapproachusedhasbeentodevelopspecificapplicationcomponentstargetedtospecifictasks,connectthemtoeachotherviamessagingorRESTservicesdependingupontheirapplicationrole(backendprocessingorservicedelivery),andprovidescalingcapabilitiesthatdetectloadoneachcomponent(CPU/threadutilizationanditsfeedingqueuestate)andscalethenumberofinstancesofthatcomponentbasedondemand.

Primarycomponentdescriptions:

ModelEngine–Therearetwomethodologiesappliedwithinthemodelengine.ThefirstisusedforfreewayestimationandimplementstheCTMalgorithmforsimulationandanensembleKalmanfiltertoassimilatereal-timeroadsensordata.Thisimplementationusesauserdefinedroadnetwork,accompanyinginfrastructureelementsincludingrampmetersandsensors,trafficdemand,traffic


61

behaviorinformation(splitratiosatintersectionsandfreewayramps),androad/trafficcharacteristicsrequiredbytheCTMalgorithm(fundamentaldiagrams).CTMbasedsimulationcanbeusedbothinestimationsofcurrentstateandpredictionsoffuturestate,butisusedonlyforestimatingcurrenttrafficstateonfreewayswithintheICMsystem.

Thesecondmethodologyappliedinthemodelengineisusedforarterialestimation.Thismethodusesanalgorithmusingintersectionsensing,signaltiming,andcycleinformationtoproduceanestimatedtrafficstateonthecorridorarterials.

Foreitherestimationmethodology,themodelenginereceivesarequestforamodelruncontainingthescenariotoberunandthedesiredconfigurationparameters.Themodelenginethenstartsacontinuingrunofthemodelandoutputsthelinkstate(trafficdensityandspeed)foreachroadnetworklink.

PredictionEngine–ThepredictionengineisanimplementationofTSS’sAimsunsoftware.ItincludestheAimsunsimulationsoftwareaswellasacomponentthatbuildssimulationmodelsforuseinthepredictionworkflow.Tobuildasimulationmodel,thiscomponentcombinesabasesimulationmodelwithdatafromthedatahubindicatingcurrentcorridorassetstate(signals,ramps,signs,etc),currenttrafficstatefromthefreewayandarterialmodelengines,andtheresponseplansfromtheresponseplanmanagementsystemtocreateamodelthatcanbeusedtoevaluatearesponseplan.Italsoprovidesthepredictionmetricsforthatresponseplanthatarerequiredforpresentationtotheuserandpassedtotherulesengineforresponseplanrecommendationandselection.

ProjectManager/ProjectManagerApp-Theprojectmanagerappallowsexternalsystemstointeractwiththemodelingsystem.ProjectmanagerappprovidesRESTservicesandmessagingtoinitiateactionsbytherestofthesystem.TheprojectmanagerappisservedviaaTomcatapplicationserver.

ScenarioBuilder-ThescenariobuilderisusedtocreateaCTMmodelscenariotoberun.Itisrarelyused,butmaybeusedwhencorridorinfrastructureelementsaremodified,suchasarampmeter.Itisaback-endcomponentthatreceivesmodelcomponents(roadnetworks,intersectionsignals,rampmeters,trafficdemandandsplitsets,etc)fromtheprojectmanagerappandbuildsamodelsuitableforrunninginthefreewaymodelengine.

Calculators-Thecalculatorsareusedtotakethemodelenginelinkstatedataandprocessitforconsumption,combiningarterialandfreewayestimation,calculatingspecificmetricsforanalysis,andprovidingvisualizationinformationfortheCMS.

PersistenceWorker-Persistenceworkersarecomponentsthataredesignedtoeithertakedatafromaqueueortopic(modelenginedata,model/scenarioinformation,orcalculatoroutput)andpersistitinoneofthedatastores(PostgresorCassandra)or,uponrequest,retrievedatafromoneofthedatastoresandplaceitontheappropriatequeueortopicforconsumptionbydownstreamprocesses.

ReadersandProcessors-Thesecomponentsareusedtoretrievedatapushedfromthedatahubandplaceitintoaqueueortopicforconsumption(reader),ortoretrievedatafromaqueueortopicandprocessitforconsumptionbytheestimationorpredictionengines(processor).


62



63

8. SECURITYDESIGNSecuritydesignfortheICMsystemisbaseduponthefollowingprinciples:

• Minimizeattacksurfaceo Minimalexposuretopublicnetworkso IsolatenetworksubnetstoprotectsensitivedataandprocessesanduseDMZforpublicly

exposedcommunicationpointso Limitoreliminateaccesstoallinternalsystemservers

• Authenticateallconnectionso Usecertificatebasedauthenticationbetweensystemso UserslimitedtoCMSsystemaccessandCMSsystemauthenticationprotocols

• Encryptallexternalfacingcommunications(data-in-motion)andsensitivedatastores(data-at-rest)

• Isolate individual processes and access only by those processes or people that require access(principleofleastprivilege)

• Automatedsecurityandprocessmonitoringo Killallfailedornon-respondingprocesseso Verifyconfigurationofalllaunchedprocesseso Monitorsystemandprocessaccessandaccessviolations

• Automatesystemlaunchprocesses• Validateallincomingdata

The system design, based on independent services, limited access to data stores, segmentedresponsibilities,andclouddeployment,providessignificantopportunityforenhancedsecurity.Eachoftheareaslistedabovearedescribedbelow.

8.1. MINIMIZEATTACKSURFACE

Thereareseveralmethodstobeemployedtominimizethesystemsattacksurface.These includethefollowing:

• SecurenetworkconnectionstotheICMsystem.o Useofdedicatedfiberconnectionsand/orsecureVPNconnectionstothevariousTMCs

involvedinprovidinginformationandexecutingresponseplans.o UseofasecureAWSDirectConnectconnectionprovidedbyAT&TsNetBondservice.o All connections to external systems pass through District 7 TMC Foreign Entity (FE)

firewall.o AllconnectionsaresecuredviaVPCsecuritygroupinboundandoutboundaccessrules.

• Nodirectconnectionstothepublicinternet.• ThesystemrunswithinaVirtualPrivateCloud,separatedinto“public”,“shared”,and“private”

subnets. Two “public” subnets exist, one to receivedata fromTMCs, andone for theCMS tomanage and execute response plans. “Public” subnets are exposed only to private, protectednetworkswithinTMCsandonlythroughsecureconnections(describedabove).“Shared”subnetsareusedforthemessagingsystems,providingasecurebridgebetween“public”and“private”subnets.“Private”subnetsareusedforsystemprocessinganddatastoragecomponents.


64

• Onegoalofthisdeployment is touseautomationforsystemlaunchanddeployment,withnohumaninterventionrequired.ThisallowsfordeploymentwithoutSSHkeysonindividualAWSEC2instances,since,inthecaseofsystemfailure,theresponseistoisolateorkillthefailedsystem,and,usingautomation,deployanewsysteminitsplace.WithoutSSHkeys,thereisnoaccesstotheOSofanydeployedsystem.

8.2. AUTHENTICATION

Strongauthenticationshallberequiredforallsystemaccess,includingallconnectionstointernalservices.Thiswillinclude:

• Two-factorauthenticationrequiredforAWSadministration• Usecertificatebasedauthenticationforexternalsystemscommunication

TheuserswillbelimitedtoaccessoftheCMSsysteminterface.Nootheraccessshallbegrantedtosystemusers. Authentication of users shall be based on the security protocols and implementation of eachindividualvendor.SincetherearethreedifferentCMSsystemsthatwillbedeployedatdifferenttimesbasedontheirevaluationperiod,authenticationmethodsmaydifferandimplementationshallcertainlydiffer.

8.3. DATAENCRYPTION

Encryption, via SSL, shall be used for all communications with external systems. This includescommunicationwithalldatahubreadersfromTMCsandwitheachCMSsolutiontoTMCs.

Inaddition,whileitisnotexpectedtoberequired,alldatastoredinanyofthedatabases,orAWSdatastoresuchasS3shallbereviewedwithCaltransfortheneedtoencryptthedatastore.Ifanydataelementistobeencryptedinstorage,itshallbeencryptedwhentransportedinternallyviathemessagingsystems.

8.4. PRINCIPLEOFLEASTPRIVILEGE

The principle of least privilege is defined as ensuring that everymachine, process, and user are onlyallowedtoaccesstheinformationandresourcesrequiredforitsoperationandpurpose.Allotheraccessisprohibited.

TheICMsystemshalladheretothisprinciple,usingthefollowingdesignelements:

• AccesstoEC2instancescontainingdatabasesareonlygrantedtopersistenceworkers,specificreaders(forMongoDBtransformationpipelines),Spark,andPMA(modeling).

• EC2 instances requiring only access tomessage brokers are restricted to only thosemessagebrokersrequired.

• NoSSHaccesstoEC2instances.• TMC and any other external access is limited to specific data hub readers designated for

communicationwiththatTMCandCMScomponentsrequiredforcommunicationwiththeTMC.


65

• DSS,CMS,anddatahubsystemsshallencapsulateallaccesstointernalcomponentsthroughtheirspecific gateways and interfaceseither inpublic (externally facing communications)or shared(internalcommunications).Nootheraccessshallbegranted.

• AWS IAM groups, users, and roles shall be configured in accordance with principle of leastprivilege.

• AccesstoGraylog,database,andmessagebrokeradministrationshallbegrantedonlytosystemadministratorsforeachspecificservice.

NOTE:CMSsecurityisdependentuponspecificimplementationofeachCMSsystemandconfigurationofsecuritywithintheCMSsystem.

8.5. AUTOMATEDSECURITYANDPROCESSMONITORING

While automated security and processmonitoring is not likely to be configured fully upon the initiallaunch, it is intendedthatthiswillbe implementedduringproductionoperations inclosecooperationwithCaltransIT.ThisshallincludetheuseofCloudTrailandCloudWatchtoaccomplishthefollowing:

• Killallfailedornon-respondingprocesses• Verifyconfigurationofalllaunchedprocesses• Monitorsystemandprocessaccessandaccessviolations• Quarantineorkillandrelaunchanysuspectedcompromisedsystemsoroperations• ConductregularautomatedAWSinspectionsofthesystemconfiguration

8.6. AUTOMATESYSTEMLAUNCHPROCESSES

Toensureconsistentsystemlaunch,deliveryofsystemservices,andsecuresystemconfigurations,allsystemlaunchprocesseswillbeautomatedusingCloudFormationor,inthecaseofsomemodelingcomponents,useoftheEC2APIsandprogrammaticlaunchofcomponentsfromcontrolledsystemimages.Thiswillincludetheautomationofsystemupgradesandpatches.Thiswillminimizethepossibilityoftheintroductionofinconsistentandincorrectsecurityandsystemconfigurations,andprovidetheabilitytomoreeasilymonitorforandcorrectsystemdeficiencies.

8.7. VALIDATEALLINCOMINGDATA

Topreventdenialofsystemservicesorsecurityissues,aswellasensureproperoperationofthesystem,alldatareceivedbythedatahubshallbevalidatedtoensurethatiswell-formedandwithinreasonabletolerancesforsystemprocessing(volume,content,timing,etc.)


66



67

9. SYSTEMINTERFACEANDMESSAGESYSTEMDESIGN

ThereareseveralprimaryinterfacesdefinedfortheICMsystem.Theseinclude:

• Datahubinterfacetoexternaldatasources,primarilythedifferentTMCsprovidingcorridorassetinformationsuchasassetinventoriesorassetstate(suchasintersectionsignalcycleinformation).

• DatahubtoDSSinterface• DatahubtoCMSinterface• CMStoexternalcommandtargets,primarilythedifferentTMCsthatwillexecuteresponseplan

actionsbasedonTMDDcommandsreceivedfromtheCMS.

In general, communicationswithexternal TMCsanddataprovidersor consumers is accomplished viaTMDDSOAPbasedmessaging,usingtheConnectedCorridorsmodifiedversionofTMDD.This includesthedatahubcommunicationwithexternaldatasourceswhichprovidethedatanecessarytooperatetheICMsystemandtheCMSinterfacetothecommandtargetTMCswhichexecutecommandsreceivedfromtheCMS.ThedatahubtoCMSinterfacehasaSOAPinterfaceusingthesamemodifiedTMDDspecificationforuseifdesiredbyCMSvendors.ExtensionstotheTMDDspecificationforresponseplanexchangeandapprovalworkflowshavealsobeenaddedfordatahubtoCMSandCMStoCaltransATMSinterfaces.

ThedatahubtoDSSinterfaceusesActiveMQandJSONformattedTMDD-likemessages.ThedatahubtoDSS interfaceuses thedatahub’sdatagatewayand theDSS interface tocommunicate,with thedatagateway’sApacheCamelimplementationpushingmessagesontotheDSS’sActiveMQbrokertopicsandqueues,andtheDSSinterfaceprovidingtransformationandroutingforthemessageswithintheDSS,aswellasprovidingacorrespondingpathformessagesfromtheDSStothedatahub’sdatagateway.

InadditiontotheSOAPinterfaceprovidedbythedatahubdatagatewayfortheCMS,optionallytheCMSmayuseActiveMQandthedatagatewaywillcommunicatewiththeCMSinthesamemannerastheDSS.

WithindatahubandDSS,theuseofindependentprocessescommunicatingviamessagingisakeydesignelement,whichusedproperlyprovidesanumberofsignificantbenefits.

• Parallelizationofprocessing• Scalabilityofservicesforhighdatavolumes• Improvedresilience,simplifiedredundancy,andfastfailover• Improvedflexibilitywiththeabilitytoaddadditionalcapabilitiesorchangesystemconfiguration

withoutinterruptiontoexistingservices• Abilitytoaddadditionalcorridorswithminimaleffort,cost,anddisruption• Abilitytomaintain,patch,orupgradethesystemwithminimalornodisruptioninservice

Acriticalelementofthisdesignisthemessagingsystemsthatlinktheindependentservices.Therearetwo primary messaging systems used to accomplish the linking of these services and maintaincommunicationwithinandbetweensystemcomponents:

• ActiveMQ• Kafka


68

9.1. DATAHUBINTERNALMESSAGING

ThedatahubusesbothApacheActiveMQandApacheKafkamessagingsystemsforconnectingitsinternalservices. It is important to note that the design of the data hub is basedon loosely coupled servicesconnectedbymessaging,andorchestratedbythecommandgateway.Themessagingonlyprovidesdatatransportandcommandcommunications.Theservicesthemessagingprovideshavenoknowledgeoftheotherserviceseitherprovidingthedatausedbythoseservices,northeservicesconsumingthedatatheyprovide.Onlytheorchestrationserviceprovidedbythecommandgatewayhasanyknowledgeofthefullsuiteofservices,andasaresultoftheworkflowsinherentintheconnectionsmadeanddefinedwithinitsworkflow engine (Conductor). This has significant advantages in scalability, speed of processing, andflexibility,butalsocomeswithouttransactionality.ThereisthepotentialformessagelossthatmustbeaddressedwithintheworkflowsdefinedwithinConductorandwithinthedesignofservicerecoveryintheeventofsystemfailure.

9.1.1. DATAMESSAGINGANDKAFKA

Kafka isaclustered,highvolume,highspeed,highlyscalable,persistentmessagingsystemengineeredspecifically for real time data pipelines and streaming data applications. Itwas developed initially byLinkedIn,andreleasedasanopen-sourceproductin2011.

ThedatahubusesKafkaformovingdatabetweenitsvariousservices,asadatatransportmechanismforitsdatapipelines.ThedatahubwillusethefollowingconfigurationsforKafkamessaging:

• AminimumofthreeKafkanodes,scaledbymessagevolumeexperienced• TheuseofmultipleKafkapartitionspermessagetopicispreferred,however,singlepartitionsare

usedwhenmessagesaretoremainevent-timeorderedperdatasource• Zookeeperforprocesscoordination

Datamaybeencryptedintransitifnecessary.

Anamingconventionfordatahubtopicswillbeutilized:

Host.Org.Corridor.AssetType.Description

Anexampleofthismightbe:CT.D7.210.IntersectionSignal.ProcessedPlanInventory,wheretheHostisCT(Caltrans), theOrg isD7 (District 7), theCorridor is 210, theAssetType is Intersection Signal, and theDescription is Processed Plan Inventory. This allows for deployment inmultiple districts andmultiplecorridorsandmaintainsahumanreadablenamingconvention.

9.1.2. COMMANDMESSAGINGANDACTIVEMQ

ActiveMQprovidesarobustandreliablemessagingsystemthathasbeeninuseinproductionsystemssince2004.IthasbeenanApacheprojectsince2007,withmanyyearsofreliableoperation.

ThedatahubusesActiveMQforitscommandmessaging,providingacommunicationmechanismfortheorchestrationofservicesconductedbyitscommandgateway.Thegeneralmechanismistohaveatopicforservicestoprovidestatustothecommandgateway,andavirtualtasktopicusedforthecommandgateway to send commands to the individual services. This extends also to the data gateway for


69

configuration of dynamic endpoints required forworkflows that involve theDSS and CMS, aswell ascommunicationofrequests,responses,andstatusinformationexchangewiththeCMSandDSS.

9.2. DSSINTERNALMESSAGING

TheDSSusesApacheActiveMQasitsonlymessagingmethod.Aswiththedatahub, it is importanttonotethatthedesignoftheDSSisalsobasedonlooselycoupledservicesconnectedbymessaging.Theprimarydifferencefromthedatahubhowever,isthattheDSSisacombinationofsubsystems–primarilythe modeling and the response plan management components. Orchestration is not centralized.OrchestrationofthemodelingsystemisprovidedbytheProjectManagerApplication.Theresponseplanmanagementdoesnotrequireorchestrationofindependentservices,andworkflowsaregovernedbytheresponseplanmanagementcomponent.TheDSSInterfaceprovidesacriticalfunctionofdistributionandtransformationofmessagesforeachconsumingsystem.AsharedActiveMQmessagingsystemprovidesallmessagingfortheDSSanditssubsystemsfordata,command,andstatusinformation.

Aswiththedatahub,themessagingonlyprovidesdatatransportandcommandcommunications.Theservicesthemessagingprovideshavenoknowledgeoftheotherserviceseitherprovidingthedatausedby those services, nor the services consuming the data they provide. Only the orchestration serviceprovidedbytheProjectManagerApplicationformodeling,ortheresponseplanmanagementcomponentof the response plan management system has any knowledge of the full suite of services of theirrespectivesubsystems.TheDSSinterfaceprovidesthegatewaytothedatahub,andActiveMQprovidesthebridgebetweenresponseplanmanagementandmodeling.Inthesamemannerasthedatahub,thishas significant advantages in scalability, speed of processing, and flexibility, but also comes withouttransactionality.There is thepotential formessage loss thatmustbeaddressedwithin theworkflowsdefinedwithinProjectManagerApplication andwithin thedesignof service recovery in theeventofsystemfailure.


70



71

10. DEFINITIONOFTERMS

Term Definition

ActiveMQ ApacheActiveMQ,activemq.apache.orgisanopensourcesoftwaremessagingsystemAimsun Aimsun(aimsun.com)isacommercialtrafficsimulationsoftwaresystem.

AlertNotificationsentbytheICMsystemtoindividualsorunits.Alertsmaybedisplayedonscreen,sentbyemail,sentbytextmessage,sentbyradiomessage,orsentbytelephone.

AmazonWebServices(AWS) Acommercialcloudcomputingservice-www.aws.amazon.com

API ApplicationProgrammingInterface(API)isadefinitionofhowasoftwarecomponentcommunicateswithexternalcomponents

Applicationlayer Asoftwarearchitectureordesignlayerthatprovidescoreapplicationfunctionsforasoftwaresystem.

ArchiveDatathathasbeenstoredforhistoricalpurposesandcanberetrieveduponrequest,usuallytoalocationandusingastoragemethodthathaslargecapacityandslowerretrievaltimes.

ATMS AdvancedTrafficManagementSystemAuthentication Verifyingauser'sidentity.

Authorization Verifyingauser'spermissionstoviewspecificdataelementsorperformspecificfunctions.

Availability Adescriptionofwhetheranassetisavailableforuseinaresponseplanornot.

Camel ApacheCamel,camel.apache.org,isanopensourceenterpriseintegrationplatform,providingsoftwarecomponentsforroutingofsystemmessages.

Cassandra ApacheCassandra,cassandra.apache.org,isanopensourcetablebasedNoSQLdatabasesystem.

CloudFormation AnAWSservicethatprovidestheabilitytocodeandautomateAWSservicesprovisioningandultimtimately,systemenvironmentsandcomponents.

CloudTrail AnAWSservicethatlogsuseractionswithinanAWSenvironment.CloudWatch AnAWSservicethatprovidesmonitoringserviceswithinanAWSenvironment.CMS Changeablemessagesign.Includesbothfixedandmobiledevices.

CommandGatewayAcomponentofthedatahubthatprovidesserviceorchestrationandworkflowservicesforthedatahubandforprocessesthatcrossdatahub/DSSanddatahub/CMSboundaries.

ConfigurationManagement

Maintainingatimelineofchangestoanentity,ensuringtraceabilityofchangesintime,content,andauthorofthechange.


72

Term Definition

CorridorAsset

AnycorridorelementavailableforusewithinaresponseplanorthatprovidesinformationtotheICMS.Assetsincludethefollowingtypesofelements:

• Intersectiontrafficsignals • Rampmeters • Organizationalunitsorindividuals(peopleresources) • Equipment • MobileorstationaryCMSelements • Trafficsensorsandothermeasurementdevices • Communicationelements(511,HAR,thirdpartyinformationproviders) • Parkingfacilities

• Transitelements

CorridorManagementSystem

OneofthethreeprimaryICMsystemcomponents.Thecorridormanagementsystemprovidesauserinterrfaceandresultingwayforalloftheprogramstakeholderstointeractwiththesystemandprovidestheabilitytoexecuteresponseplansthroughthevariousstakeholdersystems.

CorridorState

Informationdescribingthestateofthecorridorataspecificpointintime.Stateinformationincludes:

• Corridorroadnetworkclosures • Corridorroadnetworklaneblockages • Incidentinformation

• Eventinformation

• Assetinventory

• Assetstate

• Sensorinformation

• Transitinformation

• Transitstate

• Trafficconditions(density,flow,velocity)ontheroadnetwork

• Responseplanscurrentlyimplementedorintheprocessofbeingimplemented

CurrentTrafficState

Determiningavalueoftrafficdensity,flow,andvelocityforeachlinkintheroadnetworkatthecurrenttimeandwiththedataavailableatthecurrenttime.Alsoincludesvaluesforcurrentturnvolumesandratiosateachturnmovementwithintheroadnetwork.


73

Term Definition

DataGateway

AcomponentofthedatahubthatprovidesaninterfacebetweenthedatahubandtheDSSaswellasbetweenthedatahubandCMSsystems.ThedatagatewayalsoprovidesroutingservicesformessagessentorreceivedtotheDSSorCMSandinternaldatahubcomponents.

DataHub AcorecomponentoftheICMsystemwhichhasprimaryresponsibilityforreceiving,processing,storing,andprovidingdataforallICMsystemcomponents.

DataQuality

AmeasureofthequalityofdatabeingreceivedbytheICMsystem.Factorsconsideredindataqualityofaspecificassetortypeofassetsinclude:

• Percentofworkingassets • Individualassetstate,includinglevelofassetdegradation

• Percentoftimereliabledataisprovidedbytheasset

• Specificfilteringoralgorithmicverificationofincomingdataspecifictotheassetorassettype

DatabaseLayer Asoftwarearchitectureordesignlayerthatprovideslongtermdatastorageforasoftwaresystem.

DecisionSupportSystem

AcorecomponentoftheICMsystem,providingtrafficconditions,incidentandeventinformation,forecastsoftraffic,proposedresponseplansandassociatedtrafficforecasts,assetinventoriesandassetavailability,maintenanceinformation,organizationalinformation,roadnetworkconditions,andpreviouscorridorplanningandstudyinformationtouserstosupportcorridoroperationsanddecisionmaking.

Delay Ameasureofthetypicaltimeatravelerwouldexperiencealongarouteoverandabovethetimethetravelerwouldexperienceatfree-flowtrafficconditions.

Demand Ameasureoftrafficdemand(flow)atanentrancetotheroadnetworkorbetweenspecifyentryandexitpoints.

DMS DynamicMessageSign.ThisisthesameasaCMS(seeabove).

DMZAmethodofprovidingsecurityforenterprisesystemsbyprovidingaphysicalorlogicalnetworkthatseparatesexternalorpublicfacingsoftwaresystemlayersfromprivatesoftwaresystemlayers.

DoNothingPrediction/Response

Atrafficpredictionbasedonaresponseplan/theresponseplanitselfthatincludesnochangestoanycorridorassets'normal,preprogrammed,responsestotrafficbehavior.

Drools AnopensourceJavabasedrulesenginesoftwarecomponent.(drools.org)

EC2 AnAWSserviceprovidingcomputingcapabilities(virtualordedicatedserverresources)ondemand

EDW EnterpriseDataWarehouseisatypeofsoftwaresystemthatprovidesconsolidation,reporting,andanalysisservicesforabusiness,usuallywithmultipledatasources.

ElasticMapReduce(EMR)

AnAWSservicethatprovideshostedhighvolume,highspeeddataprocessingservices.


74

Term DefinitionensembleKalmanfilter

AMonteCarloimplementationoftheBayesianupdateproblem,usedwithinthetrafficestimationsystem

Event

Aplannedorunplannedoccasionoractivityoccurringwithinthecorridorthatisnotcausedbytrafficactivitybutaffectstrafficconditions.Examplesincluderoadmaintenanceactivity,amajorsportsevent,apubliceventsuchasaparade,andaconcertorartsactivity.

Geospatial Relatingtolocationontheearth.

Glacier AnAWSserviceprovidingarchivaldatastorageservices.

Graylog Graylog(graylog.org)isanopensourcesoftwaresystemlogstorage,management,andreportingservices.

GTFS GeneralTransitFeedSpecification.Thisisadataformatusedtorepresenttransitroutesandschedulesonelectronicmaps.

HAR HighwayAdvisoryRadio,usedforcommunicatingtotravelers.

IAM AnAWSservicethatprovidesusersecurityserviceswithinanAWSenvironment(IdentityAccessManagement)

ICM IntegratedCorridorManagement

ICMCoreSystemThecoretechnicalfunctionalitiesoftheICMsystem.TheCoresystemiscomprisedprimarilyofthedecisionsupport,datahub,andcorridormanagementsystemcomponents.

ICMEnvironment Allthecomponents—includingpeople,organizations,hardware,andsoftware—involvedinthefunctioningICMsystem

Incident Traffic-relatedincident,suchasanaccidentordisabledvehicle.

IncidentConfirmation Positiveconfirmationwithinthesystemofanidentifiedtrafficincident.

IncidentIdentification Identificationofatrafficincident.

Inventory Acollectionofassets.

JMSJavaMessageServices,JMS,isacomponentoftheJavaEnterpriseEditionthatprovidesamessagingstandardandcomponentsandlibariesforuseinsoftwaresystemstoimplementthatstandard.

JSON JavascriptObjectNotation-amethodofdescribingdataorjavascriptsoftwareobjectsforexchangebetweensoftwaresystems

Jurisdiction Geographicandassetownershiporcontrolbyaspecificorganizationalorgovernmentalentity.

JurisdictionalRestriction

Arestriction,generallyonacorridorassetorroadnetworkelement,imposedbyanorganizationalorgovernmentalagency.

Kafka ApacheKafka,kafka.apache.org,isanopensourcesoftwaremessagingsystem


75

Term Definition

LCS LaneControlSignal.SameacronymisalsousedforLaneClosureSystem.

Link Adefinedsectionofroad.

MicroservicesArchitecture

Amethodofsoftwaresystemarchitecture,usingacombinationofsoftwarecomponentsandmessagingtomeetitsobjectives,thatischaracterizedbythefollowing:1.Utilizationofsmaller,independentsoftwarecomponentswithsingularorverylimitedfunctionsandpurpose.2.Loosely-coupledconnectionofthosesoftwarecomponentsbymessaging,generallyREST,JMSorsimilartechnology.3.Welldefined,lightweightcommunicationsbetweenservicesovernetworkcommunications

MLLib AnApacheSparksoftwarelibrarythatprovidesmachinelearningserviceswithintheSparkframework.

MongoDB AnopensourcedocumentbasedNoSQLdatabasesystem(mongodb.com).

n-tier

Amethodofsoftwaresystemarchitecturethatischaracterizedby"n"layersofsoftwarefunctionalbreakdown.Atypicaln-tierarchitecture,characterizedas3-tierarchitecturehasthreeindependentsoftwaredesignlayers-userinterface,application,anddatabaselayers.

NetflixConductorNetflixConductorisanopensourceserviceorchestrationsoftwaresystemthatprovidesworkflowmanagementandservicecoordinationformicroservicebasedsystems.

NodeApointofconnectionbetweentwoormorelinks,oftenlocatedatintersections,freewayrampdiversionsorends,changesinlaneconfiguration,orchangesinroadattributes(suchasspeedlimits).

OperationalStatus Theworkingstateofacorridorasset—generallyworking,degraded,ornotfunctional,dependinguponthecapabilitiesoftheasset.

Persistence Storageofinformationinapermanentstore,suchasadatabaseorfilesystem.

Pipeline AseriesofsoftwarecomponentsconnectedviaawelldefinedAPIthattogetherprocessastreamofdata.

Post-event Aneventoractiontakenafteratrafficincidentandremovalorreleaseofresponseplanelementsandaftertheendoftheresponseplanduration.

Postgres Anopensourcerelationaldatabase,www.postgreSQL.org.

ProbeVehicleAvehicleequippedwithsensorsallowingthemtorecordtheposition,speed,andtraveldirectionofthevehicleatregularintervalsorwhencomingintoproximityofroadsidedevices.

ProjectManagerApplication

ADSScomponentthatprovidesanAPItotheestimationmodelingcomponentsaswellasmanagementandorchestrationofestimationmodelingservices.


76

Term Definition

Real-TimeData

Real-timedatadenotesinformationthatisdeliveredimmediatelyaftermeasurement.Dependingonthesystemprovidingthedata,thismayincludedatathatwasmeasuredafewsecondsorafewminutesago.Intransportationsystems,thistypicallymeansdatathat15-minuteoldorless.

RelationalDatabaseService(RDS) AnAWSservicethatprovideshostedrelationaldatabaseservices.

ResponseCrew Anyorganizational(humanandequipment)assetsthatrespondtoanincidentorevent.

ResponsePlan

AcollectionofactionspreparedandevaluatedbytheICMsystemforimplementationinresponsetoaneventorincident.Responseplansmaybeinthefollowingstates:

• Development-Theselectionandassemblyofresponseplanelements • Evaluation-Systemgenerationoftrafficforecastbasedontheresponse

planandanalysisoftheforecastandotherresponseplancomponents

• Proposed-Recommendedbythesystemforimplementationbasedontheevaluationoftheplan

• Selection-Selectionofaplantobesubmittedforapproval • Active-Approvedandinimplementation

Responseplansmayincludeoneormoreofthefollowingdeploymentelements:

• Recommendedtrafficreroutesaroundanincidentorevent • Intersectiontrafficsignalchanges • Rampmeterchanges • Organizationalassetdeployments • Equipmentdeployments • CMSchanges • Communications

Requiredadditionalsupportingelementsofaresponseplaninclude:

• Approvalrequestsandresponses(iftheresponseplanisproposedforimplementation)

• Trafficstateatthetimeofresponseplandevelopmentinitiation

• Trafficforecastbasedontheresponseplandeploymentelements • Geographicareaofimpact(alsoknownasareaofinfluence) • Corridorassetstateatthetimeofresponseplandevelopmentinitiation

• Initiatingincidentoreventinformation


77

Term Definition

• Implementationresults,includingsuccessorfailureofeachresponseplanactionandtrafficstateinformationthroughouttheresponseplanduration(iftheresponseplanisdeployed)

ResponsePlanDevelopment

CreationofoneormoreresponseplansinresponsetoanincidentoreventbytheICMsystem.

ResponsePlanImplementation Executionofresponseplandeploymentelements.

ResponsePlanManager

AcomponentoftheDSSthatprovidescontrolandorchestrationservicesforthedevelopmentofresponseplans

REST RepresentationalStateTransfer(REST)isasoftwaredesignmethodthatprovidescommunicationbetweensoftwarecomponentsviaHTTPprotocol.

Route Aninterconnectedcollectionofroadlinksthatcreateasinglecontinuouspathbetweenanytwopointsintheroadnetwork.

Rule Asingleelementoflogic,expressedwithinaformatanddialogthattherulesenginecanunderstandandprocess.

Ruleset Acollectionofrulesandanyinstructionsfortheirexecutionintendedtobeexecutedasagroupwithintherulesengine.

RulesEngine

AcorecomponentoftheICMsystemthatincludesanoff-the-shelf(commercialoropen-source)softwaresystemthatallowsuserstodefine,edit,ordeleterulesthatgovernspecificlogicappliedtospecificprocesses.Therulesengineexecutesthoserulesatruntimeinthecontextofaprocesswhentheprocessisinvoked.ArulesengineisspecifiedwithintheICMsystemtoallowuserstodefineidentificationoftrafficincidents,whenresponseplansaretobedeveloped,whatresponseplanelementswillbeincludedwithinaresponseplan,andtoallowthelogicoftheseprocessestoberedefinedbytheusersoverthelifetimeofthesystem.

S3 AnAWSserviceprovidedatastorageservices.

SedaAnApacheCamelcomponentthatprovidesStagedEventDrivenArchitecturebehavior,essentiallyprovidingablockingqueuetoexchangemessagesbetweenproducerandconsumercomponentswithinCamel.

Sensor AcorridorassetthatsensesandreportstotheICMSameasurementofthestateoftheassetortraffic.

SOAP SimpleObjectAccessProtocol(SOAP)isanXMLbasedcommunicationmethodforexchangeofinformationusingHTTPprotocols

Spark ApacheSpark,spark.apache.org,isanopensourceclustercomputingplatform.SSH SecureShell-acryptographicprotocolforoperatingnetworkservices

SSL SecureSocketsLayer-acryptographicprotocolforcommunicatingoveracomputernetwork

TMC TrafficManagementCenter


78

Term Definition

TMDD TrafficManagementDataDictionary,whichisastandardforcommunicationsbetweentrafficcenters.

Tomcat AnopensourceApachewebapplicationserver(tomcat.apache.org)

TrafficForecast Apredictionofthefuturestateoftrafficdensity,velocity,andflowforeachlinkintheroadnetwork.

TrafficState Thecurrenttrafficdensity,velocity,andflowforeachlinkintheroadnetwork.

TransitState Thestateofoneormoretransitproviders,includingthetransitinventoryinoperation,theworkingstateofeachasset,andeachasset'slocation.

TravelTime

Thetimeittakestotravelbetweentwodefinedpointsalongaspecifiedrouteonthetrafficnetwork.Threetypesoftraveltimecanbedistinguished:

• Pointtraveltime—Traveltimeobservedatagivenpointintimewithintheroadnetwork

• Predictedtraveltime—Expectedfuturetraveltimealongagivenroutebasedonatravelerorvehiclestartingatripatthecurrenttimeandencounteringvariouspredictedtrafficconditionsalonghistrip

• Experiencedtraveltime—Traveltimeobtainedbymeasuringthetimeitactuallytookforapersonorvehicletotravelalongagivenroute.

Two-FactorAuthentication

Authenticationmethodthatrequirestwoformsofidentification.Acommontwo-factorauthenticationmethodistouseausername/passwordcombinationwithanadditionalmethod,suchasanadditionalhardwarekeydevice.

Userinterfacelayer Asoftwarearchitectureordesignlayerthatprovidesavisualinterfaceandcorrespondingcontrolstointeractwiththesoftwaresystem

VirtualPrivateCloud(VPC)

AnAWSserviceprovidingisolationofcloudcomputingcomponentsintoacontained,definedcomputingenvironment

Visualization Thecollectionanddisplayofinformationbythesystemfortheuser.