YAAA: Modeling concepts and workflow
YAML-based concepts and workflows to model ADAS / AD systems
YAAA provides a set of YAML-based templates for modeling the software architecture of ADAS / AD systems.
The modeling elements are:
- Interfaces define data used for communication
- Runnables contain business logic in the form of C++ code
- Activities define and represent executables that are assigned to POSIX processes
- Activity graphs define define complete applications through instantiation of activities
- Deployment maps the software applications to concrete hardware entities
- Gateways facilitate the communication to outside world (data import and export)
- Routing and Discovery handles the routing of data between producer and consumer activities, making data exchange seamless and reliable
The modeling elements are each specified in separate YAML files. This separation of concerns supports an efficient collaboration between the different roles such as software function developers, software architects and integrators and system architects.
Interfaces
Interfaces are a crucial aspect of the system, as they serve as a means of communication between different elements. Each interface specifies a data type name, facilitating the seamless exchange of information. This is achieved through the utilization of a header file that defines the relevant data types and structures.
- Actual data values are called messages
- Logically, messages are sent from a Producer to a Consumer element
- Physically, messages are exchanged through shared memory
- Multiple interfaces can be specified in one YAML file
interfaces:
- type_name: #first data type name
cpp_type: #reference to C++ namespace::type
- cpp_include: #reference to header file
type_name: #next data type name
namespace example {
struct RandomNumberInterface { #interface type def
int number{0};
};
}
Runnables
The YAAA system, at its core, is composed of the smallest computing unit known as a "runnable." These runnables encapsulate essential business logic, making them the building blocks of the system's functionality. Communication between runnables is established through input and output ports, providing a flexible and adaptable means of interaction, with the possibility of having multiple ports.
- Each port refers to one interfaces
- Business logic is implemented in separate .cpp file: onInit() is called at initialization time, onUpdate() at every runnable execution
- State allows retention of data that must outlive single runnable execution, states are defined in header files
- Each runnable should be a separate YAML file
imports:
- ... #import referenced interfaces
input_ports:
- name: #input port name
type: #input data type
policy: #define policy type
cache_size: #allocate cache size
output_ports:
- name: #output port name
type: #output data type
internal_state:
cpp_type: #reference to C++ namespace::type
cpp_include: #reference to header file
#include βrunnable_example.hβ
void RunnableExample_onInit(
const RunnableExample_InStruct &,
State< RunnableExample_State> &state,
RunnableExample_RunContext &){}
void RunnableExample_onUpdate(
const RunnableExample_InStruct &in,
RunnableExample_OutStruct &,
State< RunnableExample_State> &state,
RunnableExample_RunContext &){}
Activities
An "Activity" within the context of the YAAA system is a distinct and self-contained binary unit or executable. When running on a POSIX operating system, an activity is assigned to a dedicated process, ensuring isolation and efficiency. The core functionality of an activity is built on the concept of Directed Acyclic Graphs (DAGs), which consist of multiple coherent runnables. These runnables form the fundamental building blocks of the activity's operation, enabling a structured and organized approach to handling tasks.
- Based on stimulus, OS scheduling is triggered / activated
- Two stimulus options available: 1) Cyclic or 2) Data
- Activity outputs can be measured
- Each activity should be a separate YAML file
imports:
- ... #import referenced runnables, interfaces
stimulus:
kind: #data stimulus (cyclic not shown)
timeout_ms: #time out definition
trigger: #trigger data name
input_ports:
name: #input port name
type: #input data type
output_ports:
name: #output port name
type: #output data type
runnable_instances:
name: #runnable name
type: #runnable data type
connections:
inputs: #define input connection (from & to)
graph: #define activity-internal connections
outputs: #define output connection (from & to)
Activity Graphs
An "Activity Graph" serves as a comprehensive representation of a software system, encompassing one or multiple activities and the interactions that occur between them.
- Each Activity graph should be a separate YAML file
- Defines a complete software system
imports:
- ... #import referenced activities
activity_instances:
name: #activity name
type: #activity data type
connections:
from: #define output port of sender
to: #define input port of receiver
Deployment
In the YAAA system, "Deployment" maps activities to processor cores or shared memory sections managed by RouDi. Details like thread count and execution priority are specified. This configuration is done in a single YAML file for the entire project, streamlining the deployment process and optimizing system performance.
imports:
- ... #import referenced activity graph
hardware_instances:[] #hardware instancing syntax
roudis:
- name: #name of roudi
partition: #partition details
mempool_config: #mempool configuration
- chunk_size: #chunk size definition
- chunk_count: #chunk count definition
activity_deployment:
- activity_instance: #activity name
deploy_to: #name of selected roudi
thread_pool_size: #size of thread pool
core_affinity: #assignment to uP core
importance: #priority of activity
In/Out Gateway
The "In/Out Gateway" serves as a vital intermediary enabling seamless communication between ETAS DMS and non-ETAS DMS systems in the YAAA system. It facilitates the exchange of data, such as exporting measurements or subscribing/publishing to ROS systems, fostering interoperability across different components. These gateways establish connections to activities through their respective input and output ports, ensuring efficient data flow.
-
Two gateway types:
- βin_gatewayβ contains only output port and
- βout_gatewayβ contains only input port
- Gateways are referenced in:
- Activity graphs YAML file to define port connections to relevant activities
- Deployment YAML file to get assigned to a RouDi
imports:
- ... #import referenced interfaces
output_ports:
name: #output port name
type: #output data type
imports:
- ... #import referenced interfaces
stimulus:
input_ports:
- name: #output port name
type: #output data type
business_logic:
- cpp_type: #Reference to C++ namespace::type
cpp_include: #Reference to header file
RouDi
RouDi, short for "Routing and Discovery," is a daemon within system managing shared memory communication. It efficiently handles the routing of data between producer and consumer activities, making data exchange seamless and reliable. Although not represented as a separate YAML file, RouDi's essential configurations and meta-information are defined within the YAML deployment file. This integration ensures a compact and unified approach to system setup, streamlining the deployment process and contributing to the overall efficiency and effectiveness of the YAAA system.
