The Ohio Department of Transportation has adopted Confluent as the event driven enabler of DriveOhio, a modern Intelligent Transportation System. DriveOhio digitally links sensors, cameras, speed monitoring equipment, and smart highway assets in real time, to dynamically adjust the surface road network to maximize the safety and efficiency for travelers. Over the past 24 months the team has increased the number and types of devices within the DriveOhio environment, while also working to see their vendors adopt Kafka to better participate in data sharing.

1. EVENT STREAMING PLATFORM (ESP)
George Padavick, ODOT ESP Manager

2. INTRODUCING OUR ESP TEAM
George Padavick, ODOT ESP Manager
Mihail Chirita & Jeff Lutz, Architects
Tom Keller, Project Manager
Keshav Ramakkagari, Developer
Mahes Nayak, DBA
Ed Mack, Business Analysist

3. CHALLENGE
o Processing large amounts in real time
o Volume increasing significantly
End goal: increase safety and efficiency
DATA
FROM WIDE VARIETY OF EDGE DEVICES & SYSTEMS

4. EVENT STREAMING PLATFORM
o Ingesting, processing & disseminating
o Allowing Public & Private entities
to share, publish or consume
GOALS
A REAL-TIME TRANSPORTATION DATA PLATFORM
Supporting Drive Ohio Initiatives &
ODOT operational needs

5. 5
ESP - TECHNOLOGY STACK - CLOUD COMPONENTS
Hosting/Infrast
ructure
Containers
kubectl
deployer
Persistence
Observability
Streaming
Infrastructure
KSQL
Clusters
Connect
Clusters
Schema
Registry
Confluent
Operator
Confluent Control
Center
Applications
Inputs
Pull|EDGE|Push
Processing
KSQL|Kafka Streams|Custom
Visualizations
Kibana|Grafana|Kepler GL|Custom
Outputs
Push|REST|Stream

6. WHAT WAS BUILT
o Two principles
o Modular - can be used independently
o Generic - can be used for many use cases
PLATFORM
AKA “THE SHOPPING MALL”
ACCELERATOR FOR BUILDING AND OPERATING APPLICATIONS
Applications aka "the stores" to solve
specific business needs

7. APPLICATIONS
o Inputs - publishing data
o Outputs - consuming the data
o Processing - business logic
o KSQL, Kafka Stream or Custom programs
o Visualizations - exploring data
o Kibana, Grafana, Kepler GL, or Custom

8. INGESTION OF DATA
1) Pull
Data Producer
• Support multiple
protocols.
• No code - entirely
configurable
EdgeX +
MQTT Cloud +
MQTT Connector
Minimal
requirements form
publishing data for
both internal and
external users
2) Push
3) Push via Rest API

9. DATA OUTPUT
1) Push - Connectors
Data Consumer
• Support multiple protocols.
• No code - entirely configurable
Expose secure REST API to external consumers
Allow external entities to subscribe to streams
2) Pull - REST API
3) Stream - REST API

10. 10
APPLICATIONS - CLOUD PROCESSING
o KSQL
olow coding
oextensible language
ostill evolving/missing features
oKafka Streams
opowerful library for streaming applications
oneed to code in Java or JVM language
oCustom
omost flexibility
orequires coding - any language

11. 11
APPLICATIONS - EDGE PROCESSING
oEdgeX/Kuiper
ouse sql to define processing
oconfigurable mechanism to send data to MQTT
broker

12. 12
APPLICATIONS - VISUALIZATIONS
o Kibana/Grafana
o drag and drop data visualizations/dashboards
o some geo-spatial support
o KeplerGL
o geospatial analytic visualizations and insights
o open sourced by Uber
o Custom
o build custom UI functionality

13. 13
SUMMARY
Edge Devices via
EdgeX/Kupier
MQTT

14. 14
THANK YOU!