524-24_SMART_Grant_Software_Developer_Etch__1_.pdf

ITB No. 524-24 SMART Grant Software Developer

Development of Crash Detection and Prediction Proof of Concept Solutions Technical Proposal

February 6, 2024

The Ohio Department of Transportation Office of Contract Sales, Purchasing Services

Dr. Jack Marchbanks, Ph.D., Director

ETCH, LTD | 2967 Switzer Ave, Suite D, Columbus, OH 43219 | (614) 507-6533 | www.etchgis.com

February 6, 2024

State of Ohio, Department of Transportation (ODOT) Office of Contract Sales, Purchasing Services 1980 West Broad Street Columbus, OH 43223

RE: OhioBuys: Solicitation Invitation: 524-24 SMART Grant Software Developer Solicitation

ID: SRC0000015277

Etch, LTD (Etch) respectfully submits this proposal to the Ohio Department of Transportation (ODOT) for the Development of Crash Detection and Prediction Proof of Concept Solutions.

We are pleased to offer a team that includes Trihydro and Moove.ai to provide continuous development of the Event Streaming Platform (ESP) with the addition of real use cases to improve public safety throughout Ohio. This team consists of the variety of experts needed to successfully implement the pilot projects so they can be expanded fully throughout Ohio and potentially other DOTs across the country.

We have worked with the federal government (USDOT) and many state DOTs to provide cutting edge technology that includes machine learning data analysis that leads to predictive modeling approaches.

Our team has worked on several USDOT grant-funded projects and produced quality deliverables as well as the necessary documentation to continue grant funding.

Our team also understands the importance of stakeholder engagement and applies an agile development process for continuous testing and iterative feedback. Our Project Manager, Darlene Magold, and Technical & Application Development Lead, Jon Woyame, are local to Columbus and can provide the constant coordination that is necessary to complete this project. We have the experience and expertise to lead the development team and work closely with ODOT Stakeholders and the Program Management team. Our staff is ready to meet the goals of the SMART grant and has more than adequate capacity to meet the very strict schedule.

The Etch team will meet this project’s challenges while providing the following benefits to ODOT:

• Expertise with federal grants with both technical documentation, application development and deployment.

• Successful implementation of applications for several use cases to solve incident management and traffic issues by using various datasets (connected vehicles, device management) from both local and state DOTs.

• Access to the existing ESP team with added capacity of a machine learning (ML) partner who understands the underlying technology (Kafka in AWS) and ODOT cadence.

• A solution with a foundation of open, free, and proven technologies that can be adapted throughout Ohio, and by other states, cities, and agencies.

I am personally excited by the opportunity that this project represents, and I am confident that our staff will work well with your team at ODOT and the selected Program Management team. If you have any questions or comments, please do not hesitate to contact me directly at (614) 507-6533 or darlene@etchgis.com.

Respectfully, Darlene Magold, GISP CEO Etch, LTD http://www.etchgis.com/ mailto:darlene@etchgis.com

TABLE OF CONTENTS

SECTION I. INTRODUCTION

1.1 PROJECT UNDERSTANDING

Incident Detection and Response Initiation Crash Prediction and Proactive Mitigation

1.2 PROJECT TEAM

SECTION II. SCOPE OF WORK & SPECIFICATIONS OF DELIVERABLES

TASK 1. PROJECT WORKPLAN

TASK 2. DATA SOURCE SELECTION

TASK 3. DRAFT & FINAL SYSTEM ARCHITECTURE AND DESIGN

TASK 3.1 DATA TRANSMISSION: EVENT STREAMING PLATFORM (ESP)

TASK 3.2 INCIDENT & RISK RESPONSE RULEBOOK

TASK 3.3 SYSTEM ARCHITECTURE DESIGN

TASK 4. DRAFT & FINAL CONCEPT OF OPERATIONS (CONOPS)

TASK 5. DEVELOPMENT

Development Process and Agile Delivery

TASK 5.1 EPIC & USER STORY CREATION

TASK 5.2 INCIDENT DETECTION PROTOTYPE DEVELOPMENT

TASK 5.3 CRASH PREDICTION MACHINE LEARNING MODEL TRAINING & LIVE PREDICTING.. 16

TASK 5.4 INTEGRATION OF SYSTEM COMPONENTS

TASK 6. PROOF OF CONCEPT TESTING

TASK 7. PROOF OF CONCEPT EVALUATION

Machine Learning Model Evaluation

TASK 8. DEVELOP A PLAN FOR PRODUCTION

Proof of Concept Deployment to Production

TASK 9. DRAFT & FINAL IMPLEMENTATION REPORTS

PROJECT MANAGEMENT & PROPOSED SPRINT TIMEFRAME

SECTION III. VENDOR QUALIFICATIONS AND EXPERIENCE

3.1 ORGANIZATIONAL EXPERIENCE & CAPABILITIES

3.2 STAFF EXPERIENCE AND CAPABILITIES

Key Staff Support Staff

APPENDIX B ADDITONAL PROJECT EXPERIENCE

SECTION I. INTRODUCTION

1.1 PROJECT UNDERSTANDING

The Ohio Department of Transportation (ODOT) is seeking a highly skilled development team to assist with the implementation of a proof-of-concept for the recently awarded United States Department of Transportation (USDOT) Strengthening Mobility and Revolutionizing Transportation (SMART) grant. ODOT has already procured the Program Manager for this initiative that will work closely with the Application Development team to provide thorough documentation and a functioning prototype for two pilot use cases: Incident Detection and Response Initiation and Crash Prediction and Proactive Mitigation. ODOT also wishes to utilize Event Streaming Platform (ESP), a central environment for ingesting and outputting any transportation-related data in near real-time, to deploy these proofs-of-concept.

ODOT has a rich history with deploying intelligent transportation systems (ITS) technology throughout the State of Ohio as well as projects that span across state borders. The SMART grant has a very strict timeframe and will require a management and development team to work closely together with the stakeholders to complete the required documentation as well as deploy successful pilots based on the specified use cases that can be replicated statewide.

Etch, LTD has put together a team of professionals with Trihydro and moove.ai, that have successfully completed projects that are similar to this request for several state DOTs that include: Ohio, Wisconsin, Colorado, Hawaii, New York, and Minnesota. We have also worked on USDOT transportation technology grants throughout the US. Our experience shows the execution of application development projects that consist of an immense amount of data integration with machine learning models and artificial intelligence technologies. The results of these projects have provided entities with visualizations such as message boards, dashboards, notifications, maps, and more to make traffic decisions for safety and congestion. We have also authored detailed technical documentation to the USDOT.

The two use cases addressed in this submittal include:

Incident Detection and Response Initiation ODOT will receive air bag deployment alerts directly from vehicle manufacturers, including Honda, or other potential data sources proposed by the Etch team and the Program Management team, and automatically provide crash location and severity information to emergency responders. This will offer ODOT or emergency personnel an enhanced capability to detect, react, and respond in areas where traffic cameras and roadside units are not available.

Crash Prediction and Proactive Mitigation This includes real-time and static roadway data from disparate systems, which the Etch team can provide through moove.ai such as: speed, traffic volumes, weather, pavement conditions, work zones, average daily traffic volumes, transportation systems management, and operations studies. These will be compared to historical data to automatically infer scenarios that pose a higher probability of crashes occurring. By ingesting this data and adding a trained machine learning model in the ESP, ODOT will be able to systematically provide mitigation recommendations to the Traffic Management Center operators to reduce the risk of crashes.

Our technical team has worked with ODOT on the Event Streaming Platform (ESP) for the past several years and will use that knowledge to integrate the two use cases accurately and swiftly for an on-time deployment. We understand the intricate technology utilized by the ESP and will seamlessly utilize the subsystem architecture platform that is powered by a combination of a Kubernetes-based cluster of microservices hosted on AWS, and Kafka as a service managed by Confluent Cloud.

With flexible and seamless ingestion capabilities, ESP empowers organizations to aggregate dispersed data silos into an integrated environment. It can ingest and combine data from diverse sources to enrich understanding of events. The ESP provides advanced analytics and visualization tools that unlock deep insights from fused data to inform critical decisions across transportation operations and planning.

1.2 PROJECT TEAM

Etch, LTD (Etch) is a certified Ohio Disadvantage Business Enterprise (DBE) that will be the primary consultant that will serve as the overall Project Manager and Technical Lead for all application development tasks. Etch is a company that has a rich geospatial background and extensive experience with quantifying and analyzing information as it relates to sensor, GPS, connected vehicle environment (CVE), electric vehicle (EV), autonomous vehicles (AV), and telemetry data. Our firm provides data enrichment solutions that streamline complex datasets to be consumed by transportation applications. Etch also specializes in managing application development for public and private entities. Etch provides open-source software solutions for integration of multiple systems. Our team has created software and applications for Smart Cities (CVE, AV, Machine Learning), Connected Mobility, AVL Operations (Snow, Street Sweeping, Mowing) and Complex Sensor Fusion both in Ohio and throughout the US. Etch offers low-cost hosting and software as a service (SAAS) options while also providing custom APIs and backend services that other software platforms can consume.

Etch is best known for our agile project management approach focused on understanding customer requirements through constant collaboration. Our goal is to provide clients with not just what they asked for but also what they need. Etch relies on frequent feedback loops in the Agile project delivery lifecycle to serve as checkpoints where customers can see how requested features look in practice. This eliminates rework and contributes to the development of new knowledge and the exploration of innovative solutions.

Etch has worked on multiple United States Department of Transportation (USDOT) grants over the past several years as the application development lead. We work well with other firms, including overall program managers, to assist with technical documentation as well as provide a viable proof-of-concept that has led to full deployment. Our experience with transportation data fusion spans from small rural municipalities to large statewide DOTs. Our clients trust us to provide the latest and most innovative technology to improve workflow and maintain sustainability.

Etch will be the primary consultant for this project and the direct point of contact for the ODOT team.

Trihydro will support the Etch team with application development and ESP integration. Trihydro is an engineering and environmental consulting firm that has been in the business of providing professional engineering, environmental, and information technology services since 1984. Trihydro built the company on a foundation of ethics, safety, hard work, responsiveness, and respect which has helped earn several awards throughout our history. Most recently, in 2021, and for the sixteenth year in a row, Trihydro was ranked among the Engineering News-Record (ENR) Top Environmental Firms, considered one of the top 200 environmental firms nationally. In addition, Trihydro received three 2020 Environmental Business Journal® (EBJ) Business Achievement Awards in the categories of Industry Leadership, Information Technology, and COVID Response. The safety culture at Trihydro led to the company being awarded the Platinum Safety Award by ConstructSecure in 2021, and the “Best Overall Safety Culture Award” by the EHS Daily Advisor in 2019.

Trihydro’s corporate organizational structure is described as team-based with a horizontal structure rather than a hierarchical structure. This structure integrates corporate operations with business unit operations and project management goals which allows our project teams to cross-share resources and staff projects with the right people at the right time. As a centrally organized company with a single profit and loss center, Trihydro can and does approach our portfolio of work in a unified manner, able to seamlessly shift resources across internal business units to the projects and challenges where they will provide the best fit and benefit. There is no internal competition for projects or resources. With more than 500 employees and 28 offices, our size allows us to have a robust team of professionals with extensive experience while still being able to nimbly respond to program objectives on both the site and programmatic levels.

Over the past 37 years, Trihydro has grown from a small, Wyoming-based firm to a national firm with 28 offices and staff resources located in 37 states, including Ohio. Trihydro has successfully completed a wide variety of projects including projects such as informational technology and software development, compliance, assessment, emergency response, and environmental engineering in all 50 states.

moove.ai will assist the Etch team with incident detection and response initiation by enriching the incident event feeds with additional important situational context, like road conditions and other vehicle events, using data sources that are available to moove.ai. For Crash Prediction and Proactive Mitigation, moove.ai can utilize historical crash information from the insurance industry on the Galileo platform and integrate data provided by ODOT

(crash, hard breaking). moove.ai was founded in 2018 and is laser focused on extracting movement insights from Connected Vehicle Data and road intelligence to empower agencies to fully realize transportation safety and efficiency. moove.ai’s Galileo is a full turnkey SaaS platform that seamlessly integrates datasets and extracts unique insights to help agencies understand Safety and Sustainability issues on their roadway network.

moove.ai uses machine learning techniques to efficiently ingest, process, store, and analyze massive amounts of data and we are very proficient in cleansing and sanitizing petabyte-scale datasets to enhance their usefulness.

Detailed analyses of vehicle speed, instances of hard braking, the intricacies of road curvature, and advanced intersection analysis are vital for understanding and enhancing road safety, as well as determining RoadIQ safety scores to gain valuable insights into traffic patterns.

The RoadIQ Factory is developed on key processes and a white-box ML engine to be able to ingest, classify, integrate, and run ML/AI models to seamlessly deliver unique insights for clients that range from Crash Analytics, Work Zone Safety, Local Hazard Alerts, Traffic Management, Autonomous Driving, and User Based Insurance with a focus on improving road safety and greener mobility. moove.ai’s RoadIQ creates a safety score for each of the 50 million road segments in the Galileo platform based on real-time conditions including: Vehicle Speeds; Vehicle Volumes; Hard Braking Events; Hard Acceleration Events; Ignition ON/OFF; Slippery Road Conditions; Traffic Control Devices; Sun Glare; etc.

moove.ai uses the Google Cloud Platform and the Google Transport Hub as a central nerve center for transportation management by seamlessly integrating client data with BigQuery, Vertex AI, Bard, and RoadIQ’s Connected Vehicle Telemetry Service. A comprehensive suite of artificial intelligence and analytical tools are native to the Google Transport Hub that offers exceptional insights into the movement of vehicles.

SECTION II. SCOPE OF WORK & SPECIFICATIONS OF DELIVERABLES

The Etch team has designed a workplan that follows the project objectives closely with our philosophy of application development. Etch follows an agile process that begins with the Design based on our thorough understanding of the project scope, data, and deliverables. This includes the initial creation of draft interfaces based on system architecture, data, and workflows as identified by the Program Management team then refined by the Etch Development team. The Development phase includes implementing the design through agile sprints for the two prototypes, with iterative feedback as well as integration with the ESP. Our Test procedures will occur on the sprint level as well as integration and regression testing. The Evaluation will include feedback from user testing of the prototypes for each use case based on our test procedures and presented to the stakeholders for review and improvements. The machine learning component of the project will undergo detailed precision analysis and have an automated feedback loop to align with ground truth incident information and improve accuracy over time. The Etch team will coordinate closely with the Program Management team to align with their stakeholder engagement process.

The final step is creating the Deployment plan for the two use cases to a production environment. This will also include updating the system architecture design, if necessary, based on resource allocation and necessary infrastructure.

Figure 2.1 Overview of Agile Application Development Process

Discovery and Review Use Cases

• People process

• Tool & interface process

• Processing logic

• Data flows

Use Case Prototype System Design

• Prototype system design of use cases

• Data integration/flows with future ESP considerations

• Identify critical functions for people processes

• Design new interface to capture critical functions

• ML design and research approach to processing logic & tool processes

Prototype Testing

• Functional, scalability, & performance testing

• Prototype user evaluation & feedback

User Evaluation & Feedback

• Periodic cycles within delivery & testing cycles

• Incorporating necessary changes

• Final user acceptance

• Production deployment planning

Prototype Production Planning

• Production data integration//flow needs

• Identify infrastructure & resource needs

• Deployment schedule

TASK 1. PROJECT WORKPLAN

Etch will work with the Program Management team to modify the Project Workplan within the Project Management Plan (PMP) required in the first phase of the project. This includes refining the sprint schedule and finalizing client and internal team meetings.

Darlene Magold is the Project Manager for this initiative and will work closely with the Project Manager from the Program Management team. Darlene has worked with Program Management firms before on USDOT grants and understands the cadence of both management, documentation, and development tasks for a successful project deployment. She has led numerous application development projects and provided detailed documentation that has been accepted by USDOT for the federal grants, that were on time, and within budget. Darlene will provide the application development tasks as a part of the workplan for the development team that will be a part of the overall PMP for the entire project. Specifically, our contribution to the PMP will include:

Project Objectives. The Etch team will assist the Program Management team if the goals and objectives should be revised and provide more detail based on the application development process.

Stakeholder Engagement. The Etch team will work with stakeholders as identified in the RFP as well as help the Program Management team include other people, groups, or organizations that may have an interest or role in the project. The majority of the stakeholder engagement tasks will be led by the Program Management team. However, the Etch team will include stakeholders in the design and development tasks for the project. In the deliverable section for each task, Etch will identify areas where stakeholder engagement will be included.

Data Sources. Etch will work with the Program Management team as well as our teammate, moove.ai to determine if other OEM data is applicable in addition to the information provided by ODOT. Etch will work with moove.ai to secure agreements and data standards for OEM information, if ODOT wishes to proceed.

Activities and Tasks. The Etch team will Identify all the tasks required to complete each component and add this to the workplan for the Program Management PMP. We will further refine the task breakdown based on sprint cadence, documentation deliverables, and stakeholder participation.

Refine the Project Schedule. The Etch team has included a project schedule in this submittal but will need to finalize it based on the Program Management schedule.

Risk Assessment. This will be a part of the plan that identifies potential risks that could impact on the project. The Etch team will develop strategies to mitigate or respond to these risks.

Quality Control. This will be included in the proposal and refined in the final workplan. This includes defining the quality standards for all project deliverables.

Communication. This is critical since the development team will be working directly with ODOT, stakeholders, and the Program Management team. Our team will work with the Program Management leadership to ensure that we are in alignment with their communication schedule and work with them to integrate our meetings and correspondence.

Meetings. This will be finalized with the Program Management team in the communication section of our workplan within the PMP. Etch proposes that meetings with an agile approach will take place bi-weekly with a sprint demonstration and a review of sprint backlog.

Deliverables:

• Updated Project Management Plan (PMP) with Etch Project Workplan elements, including potential risks.

• Initial stakeholder meetings, define requirements, and establish sprint schedule for stakeholder demonstrations.

• An agile sprint schedule designed in coordination with the Program Management Team, with affordances for product owner feedback and revision.

TASK 2. DATA SOURCE SELECTION

The quality of the prototypes for the two use cases will mostly depend on the quality of the data sources and how they are combined. The team has made an initial selection of data sources that will “bootstrap” a high-quality prediction model, with the flexibility to incorporate more ODOT and partner sources as they become available. This will consist of:

Live Data. moove.ai’s Galileo platform provides timely ingestion of data from millions of connected vehicles as they travel on the roadway. The connected vehicle fleet streams hard breaking, hard acceleration, sun glare, slippery surface conditions, speed, and other elements. Aggregated traffic flow information like traffic volume and slowdowns are derived from the connected vehicle stream. The vehicle sensor data is also dynamically fused with infrastructure sensor data where available. Weather data, updated on a 15-minute interval, will be fused in with the other data sources to account for travel conditions.

Static Data. Besides live information, moove.ai also has data on the roadway network that allows static factors like curvature and traffic control devices to be weighed in for accident predictions.

Historic Accident Data. Accident prediction requires a machine-learned representation of the circumstances in which accidents occur. This representation, or model, must be built off an extensive record of historic accident conditions. It must account for the traffic, static infrastructure, and weather- and visibility-related factors. The model must also accurately weigh how these factors all contribute to a past accident. To create a model of accident causation, moove.ai relates all condition elements to datasets from insurance providers and will also incorporate data from ODOT’s historic collision database. By requiring the machine learning algorithm to predict historic accidents in an environmental context and identify daily and weekly traffic patterns, the model develops an intuition for what factors will come together to produce a high risk assessment for accidents in the future.

The resulting model will have the ability to continuously monitor the statewide network and apply this intuition to alert humans to developing safety concerns.

Enriched Airbag Data. Honda’s air bag deployment event feed will be one of the key datasets for the incident response use case. In addition to the data Honda will provide, Etch proposes incorporating events derived from Galileo connected vehicle data that can lead to a better insight on the impact and scope of the incident, giving better context to the airbag deployment message. Detecting slowdowns and hard breaking in the vicinity of an air bag deployment notice will help to identify the type and the severity of the incident and yield additional confidence in the suggested response. Furthermore, moove.ai has the capacity to augment incident data by providing information sourced from Waze.

Deliverables:

• Updated Data Management Plan (DMP) with moove.ai data sources including origin, data use, and privacy, that is aligned with a data assessment coordinated with the stakeholders and Program Management team.

• Sample data including realistic CSV mock of Honda airbag events.

TASK 3. DRAFT & FINAL SYSTEM ARCHITECTURE AND DESIGN

Etch will work directly with the Program Management team to integrate the necessary elements of the pilot use cases and ESP integration. Depending on the Program Management schedule, Etch will provide input to both the draft and final System Architecture Document.

TASK 3.1 DATA TRANSMISSION: EVENT STREAMING PLATFORM (ESP)

To move data from incident and traffic sources to the machine learning inference and end-user systems, Etch will use an “event” as the basic unit of information. An event is a snapshot of something that took place at a particular time. It can be logged permanently, which is valuable for training a machine learning system, and it can be used to trigger an action or generate another event in sequence. The ODOT Event Streaming Platform (ESP) is the ideal conduit for routing the dynamic event messages that must be consumed for the detect and predict tasks. It allows events to be moved from system to system with minimal latency and provides buffering and resiliency so that interrupted streams can be resumed. Etch will use the ESP as the information backbone to push information between the involved systems.

One of the specified project objectives for both pilot use cases is to integrate with the ESP. Etch and Trihydro have been working in the ODOT ESP environment both on the backend and on the user-facing applications side and have extensive experience with the design of the ESP. Both firms are active in creating and maintaining code repositories related to the ESP, including updates to the Infrastructure as Code definition that defines the ESP itself. This gives the team deep insight into how the platform can best be leveraged for data transmission in the two pilot use cases.

The entire project is designed with the ESP as the core for the dynamic event streaming infrastructure.

Etch will stream messages in the Apache Avro format for compatibility with the other ODOT ESP producers, consumers, and existing feeds. These streams are arranged into topics using the ESP’s open-source Kafka event platform. The project team will design the prototypes so that all data communication takes place over these Kafka topics. Each data topic created for the project will have a defined structure, using Avro schemas stored in the existing Schema Registry, and will be fed into the ESP. moove.ai has extensive experience using Kafka as a data pipeline, so their existing ingestion approach will tap into ESP data feeds and produce data for them.

Information is brought into the ESP with a library of Kafka Connect providers. Besides the standard providers offered by Confluent Hub, which can be configured without code, new connectors will be created by the project team as necessary.

The ESP is a flexible system distributed across separate components, so while the team will closely be following ESP development and keep all design decisions aligned with current ODOT best practices, this project does not propose any changes to the ESP’s core architecture. This scope is not contingent upon any in-development ESP features. We also understand the use of federal funds for this project and will work with the ODOT team to ensure that deliverables are within the confines of the grant requirements.

Deliverables:

• New Kafka data topics schema for incidents, safety predictions, and mitigations.

• Documented data flows for the Program Management team.

TASK 3.2 INCIDENT & RISK RESPONSE RULEBOOK

The Etch team will work with the stakeholders and Program Management team to develop a rulebook of appropriate incident response suggestions based on situational circumstances. The rules will also depend on workflows developed after communication with participating 911 systems.

A decision support system will be deployed in coordination with the alerts service and TMC website to present incidents and advisement to the appropriate channel of responders. The decision support methodology for incident response will be reused for crash mitigation, creating a single extensible pipeline for bringing about different types of action.

Deliverable:

Updated documentation based on the decision tree of planned responses for incident scenarios.

TASK 3.3 SYSTEM ARCHITECTURE DESIGN

To conform as closely as possible to the existing ESP architecture, the developed system will follow the microservice software pattern. Components of the system will be developed as separate projects and logically divided into separate, focused services or service extensions that can be independently managed and scaled, using web APIs to cross-communicate. After the stakeholders and Program Management team complete the evaluation and performance metrics, Etch recommends the following proposed components to be considered. Once there is consensus, the Etch team will build out the system components.

Traffic Management Center (TMC) Application This is the visible portion of the system. It is a Geographic Information System (GIS) web application hosted within the ESP Kubernetes environment. The project team proposes a map-focused design that can be both passively displayed on Traffic Management Center (TMC) screens or be used interactively on a desktop computer. It provides a combined visualization for both pilot projects, to avoid the need for two separate viewers. The site will display incidents and predicted high-risk locations with no required user input or browser refreshing for the passive display mode of operation. The application will communicate issues around the state highway network, and users can optionally interact with incidents to focus on them and see recommended mitigations. The user may have a high-level view of all statewide incidents or filter to a selected ODOT district, corridor, county, or NLF ID. The site would locally store the users view area and other preferences so that they are restored upon the next visit.

The project team will use the same UI development approach that is employed for the existing ESP user interface.

The TMC web application will be an Angular 2 application that hosts the map and dashboard elements, and data will stream to these web elements using the same WebSocket technique used by the ESP consumption UI. This will allow future ESP data sources to be displayed as overlay layers on the map. Applicable ODOT TIMs layers, such as Roadway Weather Information Systems (RWIS) towers, will be available to turn on as well. A configuration file will be provided to easily add or update GIS map layers.

The suggested approach for security for the frontend application is to use the existing ESP Single Sign-On (SSO) system to allow approved ODOT staff and potentially external users to access the application based on roles. Internal staff will be able to use their current logins to access the system without the need for a new password. Other users, such as emergency responders, can log in with ODOT external credentials. The project team will discuss with stakeholders the necessary features for this application. User authentication and authorization is more critical if users can make any sort of saved changes to the system.

Having a web-based visualization as part of the system will help stakeholders to evaluate that the suggested mitigations comport properly with actual traffic conditions. It will provide better situational context when responding to real incidents. Finally, it could be used as the basemap for displaying suggested Variable Speed Limit locations.

Streaming WebSocket Server To work well on passive display screens, the map interface must continually update with new information as events occur. For this to happen, the application subscribes to an HTTP WebSocket that is being offered by a web server operating as a system component. The microservice listens for connection requests for a desired topic and opens a long-lived connection with the user’s browser. As events occur on the incident or crash topics, they will be instantly streamed down to the client browser without the user having to make any requests or repeatedly poll the server for updates. Etch has significant experience with streaming live data to user browsers and apps and will apply the same techniques to update connected users with minimal latency.

moove.ai Cloud Sink Connector Design The sink (output) connector is the mechanism by which data is streamed to the moove.ai service to provide training data and generate inferences. The connector will be written in Java as a standard Kafka Connect plugin, and then be configured in the ESP system as desired using a no-code data approach to define data consumers. The input data topics that are needed for incident detection and crash prediction would be specified in the connector settings, and ODOT can control the stream of information to moove.ai as they would with any other output connector. Real-time data in Kafka topics that would be able to be sent to moove.ai include the current ODOT INRIX traffic metrics, RWIS sensor data, and traffic speeds and rates from Roadside Unit (RSU) edge devices.

moove.ai ML Model and Source Connector The source (input) connector is the reverse mechanism, in which data is streamed from the moove.ai prediction model to the ESP. This connector will also be a Kafka Connect plugin. It will consume machine learning inferences and detections generated by the moove.ai model and read them into Kafka topics in standard Avro format.

Vehicle Manufacturer Air Bag Deployment Source Connector This connector, or set of connectors, communicates with vehicle manufacturer systems to ingest air bag events, and translate them into Avro messages on a Kafka topic. The exact nature of this connector will depend on the mechanism by which the manufacturers can publish their alerts. If the manufacturers provide web-based REST APIs, for example, the project team will use the ESP’s built-in REST connector and configure it to poll the API every few seconds. The project team may also use the ESP’s push data source capability to generate a push API address and allow the manufacturer to send events to this address without having to host something themselves. There are multiple tools available that may provide data ingestion from manufacturers without the need to write specialized code. The connector will be configured like any other published ESP data source.

Alerts Service A major benefit of building onto the ESP is that real-world events can be pushed through the system within seconds of when they occur. Given the objective to automatically disseminate information for incident response or high-risk alert mitigation, a microservice to monitor the incident and crash prediction topics will offer a way to receive information without having to monitor a screen. Such a system allows users to receive geofenced alerts at a given email address or SMS text number.

Any alert events that fall within a geospatial boundary for each subscriber will result in an email or text message being sent. The system will have the ability to do severity or classification filtering for subscribers. The subscriptions will be tracked and maintained in the existing ESP PostgreSQL and PostGIS database for geospatial filtering, which can filter to a particular city, county, or other geospatial boundary. Depending on ODOT’s preference, the alert recipients could also be standard mailing lists, to provide more administrative capability over registrations. The alert text will be set to succinctly describe the nature of the alert and include the Location Based Response System (LBRS) location as reference to identify the location along the state highway network. Messages would be sent when an event begins and when it is resolved or dissipates.

Decision Support System (DSS) Service This service provides the implementation of the mitigation and response rule book. The DSS evaluates high-risk warnings, determines appropriate responses, and sends appropriate signals to the alerts service and traffic management dashboard. The parameters that decide what sort of mitigation should be applied, and where, will be developed in coordination with the Program Management team.

The DSS microservice will consume the stream for both the enriched incident events and the predicted safety risk topics. It will examine each event, apply the prescribed rules, and dispatch new events according to a database table of alert subscriptions. The decision about who to alert and what to say will be made by the DSS based on the documented rule book.

Both the DSS and Alerts services can be securely hosted inside of the virtual private cloud network used by the ESP.

The services will communicate on the internal network using the Istio service mesh, which applies SSL security on all API calls between the Kubernetes pods. With these security provisions, outside parties may not submit alert messages or data feeds that would produce an incorrect or harmful action.

The incident response and mitigation approaches will be transmitted via the web application and alerts service to TMC operators. The operators will be able to apply the suggestions to existing digital message signs, ramp meters, traffic signals, and other available ITS controls. The system will also suggest strategies to position law enforcement officers for traffic calming. Having the DSS control ITS devices directly is NOT being proposed by the project team for the pilot phase. The system will integrate into the TMC Advanced Traffic Management System (ATMS) as part of Phase 2.

As part of the deliverables, the project team will assist with the iterative development of a System Design Document that captures the upfront architecture approach as well as technical refinements and decisions that take place during the sprints. The high-level architecture will adhere to Figure 3.1, which delineates the relationship between the use cases, the Event Streaming Platform, and the organizational data exchange.

Deliverables:

• System Architecture Document (sections added to the Program Management team deliverable).

• Design specifications for ESP connector to send ODOT data to moove.ai for training, for implementors to build out in Phase 2 of the SMART grant if awarded.

Figure 3.1 Proposed System Architecture with ESP

TASK 4. DRAFT & FINAL CONCEPT OF OPERATIONS (CONOPS)

The Etch team will work with the Program Management team to contribute to the Concept of Operations report required by ODOT and USDOT. Our Project Manager and several other team members have been contributing authors to several documents required by the USDOT based on the “Vee” model systems engineering approach.

Since this document will act as the roadmap for the use cases, it is important that the Development team work very closely with the Program Management team.

Figure 4.1 The USDOT “Vee” model shown in the figure below has been broadly adopted in the transportation industry.

Key elements that will require coordination include:

Design specifications. The Etch team, specifically, our Project Manager, and Technical & Application Development lead will work with the Program Management team to make sure the System Architecture algins with our proposed implementation of the use cases. Since members of our team are also leading the ESP deployment, we can easily assist the Program Management team by helping define the external information ingestion process, schema, and data flow.

Data Requirements. This is a part of the initial phase of our development process and will be adjusted based on the findings of the Program Management team. This part of the report will identify what information will be required for the performance metrics and how it will be disseminated (through API, etc.). It will also adhere to any standards set by the Program Management team.

Performance Metrics. Our Business Analyst will work with the Program Management team to refine specific user stories that will be tailored to the two use cases to measure improvements to incident detection and crash prediction.

They will assist the Program Management team with defining specific metrics from the stakeholder team.

Testing. The Etch team has provided a draft test plan as a part of this submittal and will work with the Program Management team to refine it further based on the proposed schedule.

Maintenance. The Etch team will assist with providing documentation regarding the operations and maintenance procedures needed to sustain the system for full deployment. The procedures will include but are not limited to security audits, software patches and updates to the ESP, upgrades to software as infrastructure software changes, and change management process.

Deliverable:

Updated CONOPS document consisting of design specifications, data requirements, performance measures, and testing plan. Etch will also provide details regarding operations and maintenance of the two pilot use cases.

TASK 5. DEVELOPMENT

Development Process and Agile Delivery Throughout the project timeline, the Etch team will use an agile project management approach to produce output on a two-week sprint cycle. The output consists of code, documentation, incident rules, and test cases. This structure will allow the stakeholders within ODOT and Honda to provide regular feedback and follow progress on the prototypes.

Importantly, it will also allow the Program Management Team to jointly develop the project reports and will facilitate back-and-forth communication to resolve questions and concerns. The software will be accessible to stakeholders in a test environment during this process, and feedback in each iteration will be incorporated into the planning for forthcoming sprints.

Per section 2.1.2 of the RFP, the code will be available in a newly created GitHub account, jointly administered by the project team members and ODOT. Each sprint and tasks to be completed will be identified with stakeholder input and filed into GitHub’s issue tracker. GitHub’s project management features will be used to organize backlog tasks into sprints and assign individual items to developers. The issue tracking system will also be used for quality assurance purposes. Identified areas of improvement will be entered into the tracker with annotated screenshots or mockups.

Both the project team and the Program Management Team will be able to file and track issues.

The GitHub account will have multiple code repositories, each corresponding to one of the system’s microservices.

Issues can be tracked on a per-repository basis, and code will be committed to each one separately. Developers will work on “feature branches” where new functionality is limited to the feature-specific branch until it is ready to be brought into the main code branch. Once developers have coded the new functionality and provided unit tests, they submit a GitHub Pull Request (PR) and choose at least one other developer to provide a code review. Upon acceptance of the code review, a repository administrator will merge the PR and the new feature will be incorporated into the system.

Each repository will be configured with GitHub Actions, so that committed code in each PR is automatically tested, and committing code to the main branch will generate a freshly compiled and ready-to-deploy build image, using the same technique as the ESP services. ODOT may deploy these container images into the existing AWS development, staging, and production environments, and they will interoperate seamlessly with the existing Istio service mesh.

All documentation artifacts produced during sprint cycles will be hosted and shared through Microsoft SharePoint.

The documents will be directly edited within SharePoint and continuously accessible for review to the Program Management Team.

Developers for each system component will be working with mocks of the communication with other modules, so that each microservice can be efficiently developed in isolation and then integrated before the end of the sprint. During the integration phase, the mocks are replaced with the actual testing environment services, so that real data flow can occur and be tested to conform to the designed mocks.

ODOT will not be responsible for providing or managing a development environment. The development process is modeled after the existing ESP setup and has a proven track record with ODOT software development practices.

The tasks will be performed in accordance with the Project Workplan (within in the PMP) deliverable in Task 1.

TASK 5.1 EPIC & USER STORY CREATION

Etch will work with the stakeholder and Program Management team to create epics and user stories for the agile development process. The epics will consist of a collection of smaller user stories that describe a large work item. An epic is the top informational level in the agile process. User stories or personas will be created to assist the development team with vision of a software feature written from the perspective of the end user or customer.

Deliverables:

• Creation of epics and user stories for each use case.

• Creation of sprint backlog (update Project Workplan).

TASK 5.2 INCIDENT DETECTION PROTOTYPE DEVELOPMENT

The Incident Detection and Response use case will be turned into a prototype that makes use of multiple system components outlined in Task 4. For the duration of Task 5.2, these components will be programmed out to the architecture design specifications. All component code will be version controlled in separate code repositories, with new features uploaded to version control each sprint. Each component will have published unit tests to confirm that it adheres to the architecture design and stakeholder requirements. The unit tests run in isolation from other components to make sure the pieces are internally correct before they will be connected into the wider system. These test scripts will be available alongside the implementation code in version control as well. This task focuses on the individual components, which will be integrated together in Task 5.4 and undergo integration testing in Task 6.

Throughout development, Etch will work with its own ESP prototype environment in accordance with current ESP development practices, using the existing ESP infrastructure deployment scripts. After this task, data feeds will be available in the prototype ESP environment. Etch will provide a user interface and messaging systems for the prototypes.

Deliverables:

• Set up ESP environment for prototypes, hosted by Etch in AWS.

• Data flowing through prototype ESP as new Kafka data topics for incident detections and identified responses, which will be available to ESP consumers and downstream systems.

• Decision Support System microservice that uses the rulebook developed with the Program Management team in Task 3.2.

• WebSocket server that provides streaming data to the TMC web application.

• ESP connector to receive Honda air bag deployment events, initially consuming simulated mock airbag events.

• Alerts microservice with a subscription management component.

• All code located in the GitHub repository created for the project, with automated unit tests.

• TMC web-based application providing a map, dashboard, and live incident visualization using simulated or real event data.

TASK 5.3 CRASH PREDICTION MACHINE LEARNING MODEL TRAINING & LIVE

PREDICTING

The Crash Prediction and Proactive Mitigation use case requires a strong and proven machine learning approach to accurately model the state transportation network and infer the most at-risk portions based on live information.

There are two challenges that make this use case complicated. Firstly, accurate and useful results require that the system uses a model based on large amounts of historic roadway data, ingest a large amount of real-time sensing data, and then generate confident risk scores for sections of the network. The second challenge is the pilot timeline.

Data set coordination is often time intensive and typically requires cleaning and integration before being able to construct a model from the ground up so that it is possible to build a model from scratch.

The team’s solution to both challenges will be to use moove.ai’s existing Galileo datasets and training infrastructure to bootstrap a pilot model that can be deployed early in the project. This bootstrapping approach means that testing can commence without the risk of data acquisition and analysis delays.