EECS 4314: Advanced Software Engineering

Concrete
Architecture
Group Beyond
 Agenda
System Overview
Interaction of
& Top-level Architectural Styles
Subsystems
subsystems

Derivation Process Subsystem in

Concurrency
and Live Demo focus

Reflexion Analysis Conclusion Q/A

System Overview
System Overview
 Sensors and Actuators

The main interface between the cereal and I/O data

● boardd
Interface between cereal and
panda which communicates with
the peripherals.

● sensord
Reads and configures the sensors
including gyro, accelerometer,
and light sensors.

● camerad
Manages the camera data.
 Neural Network Runners

Responsible for all main ML processes

● modeld
Feeds input and the image stream into
the main driving neural network.

● dmonitoringd
Contains the logic for the driver’s
interaction with the system and the
car. It runs dmonitoring_model to
predict the driver’s head pose.
 Localization and Calibration

Responsible location processing and calibration

● locationd
Responsible for localizing the car and
describing its interactions with its
environment includes calibrationd and
paramsd

● ubloxd
Parses the GNSS data.

● rednose
Consists of Kalman Filter that is used by
locationd to estimate position and
velocity of car.
 Controls

Responsible for tasks related to planning and controlling the car’s movement

● radard
Converts raw data to canonical format.

● plannerd
Consists of two parts: lateral planning, and
longitudinal planning. Both use a Model Predictive
Control solver.

● controlsd
The service that controls the car. Receives the plan
from plannerd and converts it into signals.
 System, Logging,
Miscellaneous services

● manager
Manages the start and stopping of other
● logging processes.
Manages all the logging data. video
and sensor data is used for training
● thermald
the neural networks.
Monitors various parameters in
regarding the to the system’s health
● ui including, Power supply status CPU and
Handles the displaying of memory usage, and system
information the driver when the car temperature.
is on and also off.
● athena
Sets up a Websocket connection to the
comma.ai servers.
Process-Control Architectural Style Layered Architectural Style

Architectural Styles

Implicit Invocation Architectural Style

 Process-control

● Feedback Control System (Feedback Loop) ● Advantages

● Sensor data → ML model → Actuators - Continual improvement
● Actuators respond for safety - Makes driving safer & better
 Layered

P ● Hardware to Software
TO
cereal
● Top layer is responsible for
communicating with subsystems

D
MI ● Middle layer is the interface
panda/opendbc between software and hardware

● Lowest layer is responsible for

LO
W reading visual input data
car’s hardware / sensors
Layered
 Implicit Invocation Style

● Pub-Sub Architecture
● Publisher: cereal
● Subscribers: Subsystems / components
● Components publish messages to cereal
● Topic-based Communication
● Advantages
- Scalability
- Flexibility
- Modularity
Implicit Invocation Style

PUB
Interaction of
Subsystems
Rationale for the Interaction between Subsystems
 Subsystem in Focus:
System, Logging, and Miscellaneous services
 System, Logging, and Misc services
Publish-Subscribe (Pub-Sub):

● cereal.messaging in used in several subsystems, such as Ui,

Athenad, loggerd and Managerd.
● Enables loose coupling, flexible communication &
scalability.
● UI:
- Subscribes to messages related to device state and
control state.
● Loggerd:
- 3 types of logs
- These logs are then subscribed to by other
components for analysis, debugging, and
development purposes.
● Thermald:
Start
- Initializes a queue for hardware state updates.
- Creates a threading event, and starts threads
->
- These handle monitoring hardware states, managing
thermal conditions, and sending status updates to Connect to WebSocket Server
various components.
->
Client-Server:
Send/Receive Data

● The Athenad functions as a WebSocket client, communicating ->

with an external server (Athena) over a WebSocket connection.
● Messages like retrieving system information, setting navigation Close WebSocket Connection
destinations, listing files in a directory, and uploading files to
URLs are handled.
->
End
Derivation Process
 Derivation Process
● Source code is put it through Understand. Source Code
● Understand generates a dependency graph according
to the directory structure.
● We used conceptual architecture as a guide to see Understand
what subsystems exist and what are the components
of these subsystems.
● Using the sketch of the conceptual architecture we Dependency
manually create our concrete architecture by Graph
assigning each module manually to a subsystem.
● This results in our concrete architecture with Concrete
dependencies between subsystems. Architecture
Live Demo
 Effects of Concurrency
● Machine Learning:
○ Training dataset is divided into batches for simultaneous processing.
○ Complex neural network for lane finding relies on concurrent processing.
○ Concurrency ensures safety and efficiency in responding to diverse road scenarios.
○ Accelerates both training and testing phases, improving overall system
responsiveness.

● Devops Pipelines:
○ Automated testing of new code changes ensures a stable working version.
○ Implementation of parallelization in continuous integration tests significantly
reduces testing time.
○ Accelerates the software development life cycle, providing faster feedback during
testing and deployment.
Use Case - Lane Changing
 Reflexion Analysis
● Absences
○ Dmonitoringmodeld
○ Laika
Absences Divergences

● Divergences
○ Cereal (New Component)
○ Increased dependencies
Conceptual Concrete

Cereal was the main divergence being the main communicator between components
unseen from the conceptual architecture increasing dependencies
 Lessons Learnt and Limitations

1. A good understanding of the conceptual architecture is really important to extract

concrete architecture.
2. Tools like Understand are very helpful in extracting the architecture from a system’s
implementation.
3. Understand extracted dependencies between entities and showed us relations
between them at any level of abstraction that we wanted.
4. However, we still needed to manually determine an appropriate hierarchical
decomposition of the system structure and assign files to each subsystem
accordingly.
 Key Takeaways

● Openpilots has 5 overarching subsystems

● System, Logging and Misc. Services are
comprised of 5 main components
● Openpilot is built on 3 main architectural
patterns
● A main component from the concrete
architecture was Cereal
 Sources

1. https://blog.comma.ai/openpilot-in-2021/
2. https://desosa.nl/projects/openpilot/2020/03/11/from-vision-to-architecture
3. https://blog.comma.ai/laikad/
4. https://medium.com/@justinmilner/a-visual-guide-to-the-software-architecture-of-autonomous-
vehicles-390b1744cbd6
Thank You!
Any questions?