System representation concepts

System representation

In a highly abstract sense, an AD/ADAS system is constituted by sensors, algorithms and actuators:

• Sensors - lidar, radar, vision, etc. - feed data about the environment the vehicle is operating in to the AD/ADAS algorithms.
• Algorithms interprete data, build object models and reason about them, and finally take decisions on vehicle dynamics.
• Decisions that are then fed through the network to actuators that affect the speed and direction.

ETAS DMS provides tooling and AD Middleware to support AD/ADAS algorithm development, deployment, execution and analysis. Fundamental to ETAS DMS design is the runnable - a unit of execution. ETAS DMS connects runnables together as data flows between them to form a runnable graph with well-defined inputs and outputs. A runnable is single-threaded, has inputs and outputs and defined internal state - all of which are maintained by ETAS DMS to support the deterministic logging and replay support.

Runnables are grouped together to form an activity which is the next level of hierarchical modelling in ETAS DMS.

Activities

Runnables within the runnable graph are grouped into one or more activities.

Each activity and can be triggered by time (periodic) or by data. Data triggers can be combined to trigger in complex conditions involving multiple data items. The activity are deployed to ECUs - each activity is an process within the real-time POSIX OS process that underpins ETAS DMS.

In ETAS DMS, an activity is deterministic. Fundamentally, this means that computations run in the same order and will produce the same output when starting conditions and inputs are the same.

• Order: The ETAS DMS runnable graph places runnables in the order of their execution (note: if no dependency then parallel execution if they're given enough resources).
• Starting conditions: Determinism requires that the internal states of the runnables are the same and ETAS DMS ensures that this is recorded for supporting re-compute.
• Same inputs: ETAS DMS controlling which data samples are used for an activity execution (and as for state, these are recorded for re-compute)
• Same outputs: Determinism ensures that given a defined execution order, inputs and starting conditions => output is exactly defined

How long the computation takes can however vary, so the time when the output is produced it only known if the Activity gets dedicated resources.

Activities can be broken down into more detail.

• There's an “inbox” that handles blocking/running the activity after a stimulus - it's the gatekeeper that controls when an activity runs. The inbox also freezes inputs between the stimulus and call of first runnable and communicates that snapshot to measure for later recompute support.
• The activity defines the directed acyclic graph of runnable instances.
• There's a thread scheduler executing the runnable functions in order of their dependency
• Finally, there's an optional “outbox” that can control publishing runnable results (to dependent activities) either immediately or at end of that activation

Communication

Efficient, high-bandwidth, communication is essential to AD/ADAS. Whereas traditional automotive software has modest communication demands - for example, engine control software might typically consume much less than 1MB/s - when we consider Drive Assistance or Automated Driving software then required bandwidth will range from 100MB/s-1GB/s or more.

ETAS DMS communication uses Iceoryx. Iceoryx uses a true zero-copy, shared memory approach that allows to transfer data from publishers to subscribers without any copies in the middleware. This ensures data transmissions with constant latency, regardless of the size of the payload.

The use of true zero-copy communication with constant overheads in ETAS DMS has a number of interesting and important properties. In particular, communication scales very well and as the message size increases the bandwidth increases as well - this is because the only cost is the fixed overhead and therefore the same whatever the message size!

The ETAS DMS middleware includes a communication management server. This handles two critical tasks for the middleware; firstly as a broker connecting publishers/subscribers, and, secondly, as a shared memory manager controller segment allocation for zero-copy support.

It's useful to note here that VRTE also interfaces ARA::COM to Iceoryx and therefore ETAS DMS/VRTE support fast and efficient communication between ETAS DMS applications and AUTOSAR Adaptive applications.

Finally, ETAS DMS also supports a binding of Iceoryx to ROS, called the ROS Gateway. Users can define objects in the gateway that define the binding between ROS and Iceoryx (in either direction, so to or from Iceoryx). When ROS runtime is active incoming ROS messages are transferred to/from Iceoryx depending on the configuration of the Gateway objects.

Gateways

Communication with external components is realized with so-called gateways.

Gateways enable the connection of ETAS DMS elements (such as activities and runnables) and non-ETAS DMS elements (such as AUTOSAR Adaptive components like ara::com or ara::per). Gateways support both directions, make external protocol data available to ETAS DMS activities (in) and make output data from ETAS DMS activities available to external protocols (out). Usually, a gateway transforms the data (serialization and deserialization) and copies it into the output.

There are several types of gateways, supporting various use cases:

• ROS Measurement Gateways are used to record data communicated between activity instances
• Recording & Replay Gateways are used to transport captured data from shared-memory regions to the recording network and vice versa
• ETAS GETK gatewaysare used transport adapters provided by ETAS to support the GETK recording solutions
• ROS gatewaysuse the ROS publish/subscribe infrastructure as a low-end reference measurement infrastructure

The Gateway Construction Kit (GCK) provides a flexible tool to create gateways.