ROS ( Robot Operating System ) and Intelligent Vehicles
A self-driving car, also known as an autonomous car, driver-less car, or robotic car, is a car that is capable of travelling without human input. Is self-driving car a robot?
Robots need not be human inspired always. A car that is being driven by an artificially intelligent system can be said to be a type of robot. The reason you might not think of a self-driving car as a robot is that it does not have that walking-talking robot sitting in the driver’s seat. Instead, the computer system hidden in the underbody or trunk of the car is doing the driving. This seems to escape our attention and thus the vehicle doesn’t readily appear to be a kind of robot, though indeed it is.
ROS-Robot Operating System
Robot Operating System (ROS) is an open-source robotics middleware suite. Although ROS is not an operating system, it is a set of software frameworks for robot software development. Every robotics developer and robot designer – before the advent of ROS – would spend a considerable amount of time designing the embedded software within a robot, as well as the hardware itself. This required skills in mechanical engineering, electronics, and embedded programming. Typically, the programs engineered this way were more similar to embedded programming and electronics than they were to robotics. The main objective of ROS is to avoid continuously reinventing the wheel, and to offer standardized functionalities that perform hardware abstraction, just like a conventional operating system This is also one of the reasons why ROS has an analogous name to operating systems used in PCs. Later ROS2, was redesigned from scratch in order to solve some core issues that ROS was not designed to solve, such as security and real-time capabilities and support for large scale embedded systems. Below is the structure of ROS2
AAS – Adaptive Autosar
AUTomotive Open System Architecture(AUTOSAR) is a development partnership of automotive interested parties whose specifications supports a comprehensive set of automotive use cases. Classic Autosar is the same old AUTOSAR we have all come to know and love throughout the years. It is a standard which tackles the needs and requirements of embedded engine control units (ECUs). Adaptive Autosar addresses a new set of needs different than the usual embedded ECU related to evolving functionalities like environment perception, autonomous driving, vehicle connectivity and Car as a Service. It has a set of mechanisms that implement the runtime for the Adaptive Applications. What we call software components in the Classic Autosar environment, are termed as Adaptive Applications. The adaptive platform offers a flexible environment where the applications can be added or modified by the ECU acting as a central server. Updating the software has become all the more important as it interacts with an ever-changing environment. Going forward in this article, let’s use AAS as short form of Adaptive Autosar. Below is architecture of AAS until R20-11 release.
AAS vs ROS2
ROS2 was initially developed as a solution for robotic applications. From this starting point, it is now also used within existing autonomous vehicle solutions. One reason for the success of ROS/ROS2 could be that automotive engineers may be looking for alternatives to AUTOSAR since the extent of the platform’s standardized contents is enormous. The effort required to comply with the specification seems high, especially for developers with little AUTOSAR experience.
Lets look into a comparison and evaluation of the two platforms by focusing on the features offered by ROS against the functional clusters in AAS.
EM – Execution Management
Execution Management (EM) that comes as part of AAS incorporate below features:
1. Realizes functionalities related to platform and application life cycle management including authentication, start and shut down of applications.
2. Interacts with the OS to schedule applications
3. Resource allocation for application and communication.
Execution management in ROS2 is organized by launch files within the rcl API. Execution is realized by Executors, a concept based on using threads of the OS to realize callbacks, execute timers, service servers and action servers on incoming messages and events. The standard executor of ROS2 cannot guarantee determinism.
Some commercial solutions based on ROS2, have incorporated some adjustments to guarantee determinism. Further real-time and efficiency issues arise using ROS2 standard executors as per research paper ‘ros2 ¨ tracing: Multipurpose Low-Overhead Framework for Real-Time Tracing of ROS 2’. Seems that progress still has to be made towards satisfying automotive requirements in this context.
CM – Communication management
The communication and information sharing of applications is organized by the Communication Management (CM) API package in AAS. Service-oriented communication between all levels of the platform is realized and supervised thereby. SOME/IP is implemented middleware protocol. Data Distribution service(DDS) was added with release 18-10. While DDS and SOME/IP do have common features, there are also key differences. SOME/IP realizes an object-based service-oriented communication. Service classes for subscribers need to be pre-defined during development, making it static to a certain degree. In contrast, DDS enables dynamic runtime discovery by senders and receivers and offers more interoperability and flexibility.
ROS2 defines a middleware API called ‘rmw’ to enable the application-independent integration of DDS combined with Real Time Transport Protocol (RTPS) as the only middleware framework solution. The communication in ROS2 is organized using nodes. Each node provides a function to the system. The publish-subscribe communication is realized in a decentralized way, where nodes discover each other without an intermediate master. In contrast to Adaptive AUTOSAR, nodes in ROS2 need to be integrated at design time, but service discovery happens exclusively during runtime. This is a key difference between the two platforms. The Adaptive AUTOSAR CM makes it possible to reduce overhead where dynamic communication is not required.
SM – State Management
State Management in AAS performs below functions:
1. FunctionGroups can be requested to be set to a dedicated state.
2. (Partial) Networks can be requested to be activated or deactivated.
3. The machine can be requested to be shutdown or restarted.
4. Other Adaptive (Platform) Applications can be influenced in their behavior
5. Project-specific actions could be performed.
For instance, Platform Health Management can trigger an error recovery through the State Management service, which requests the execution manager to restart a corresponding function. Diagnostic Management can request to switch the system into different diagnostic states or initiate Update and Configuration Management to shut down system parts. For diagnostic and update purposes, Network Management will be used by the State Management to keep the network up and running during the diagnostic or update process.
ROS2 has no comparable diagnostic or update features. However, the recovery of a broken process can be realized using Quality-of-Service (QoS) characteristics. Thereby a process can be determined as dead in order to start recovery mechanisms. However, the QoS options are part of the underlying DDS implementation and only an indirect ROS2 feature.
Core types
The Core Type API in AAS package defines the basic requirements which apply to all functional clusters of the Adaptive platform. It contains a central initialization function for all included shared libraries of the ARA layer. It describes error handling and therefore separates between an error, a violation or a corruption.
Analogous to Adaptive AUTOSAR, the ROS2 client library clcpp needs to be initialized first. The client library also contains the definition of errors, such as invalid node or topic names, wrong function arguments or runtime errors. However, a clear separation between errors, violations or corruptions is not described. Thus, it cannot be derived which error led to an abortion of the whole process or threw an exception.
Persistency
AAS supports persistency of data beyond boot and ignition cycles through non-volatile memory. ROS2, on the other hand, is limited to the underlying DDS implementation concerning data persistence. Until version 0.8.2 it only supports volatile storage of data.
Time Synchronization
AAS and ROS2 follow similar approaches. In AAS, the master and slave time bases are synchronized using protocols like Network Time Protocol (NTP) or Precision Time Protocol (PTP). In ROS2, the messages can also be synchronized against each other, and different clocks are available for that purpose. The same PTP is the solution achieving the highest accuracy.
Platform health management
AAS monitors its applications with respect to timing constraints, logical program flows, state of platform. Either it may notify State management for error handling or directly monitors hardware watchdog and trigger a response.
In ROS2, these functions are not implemented by default. Yet, following ROS2’s open-source documentation, platform health management can be implemented. For example, the logging function, which can trigger various recovery routines in the event of errors, may be used to fulfill this functionality.
Identity and Access Management
In AAS this module is responsible for authentication and authorization of resource access. The IAM provides access control between ECUs and within an ECU. ROS2 also realizes access control and has authorization mechanism. The difference between the two platforms is mainly that AUTOSAR provides adaptive authentication and authorization also within an ECU, whereas ROS2 makes no statement in this respect.
Diagnostics
In AAS, the diagnostic API package describes a Unified Diagnostic Services (UDS) compliant implementation , provides functions for the Ethernet-based Diagnostic over IP (DoIP) layer and is expected to be extended to include traditional automotive networks such as CAN. ROS2 doesn’t contain UDS compliant diagnostic functionalities. Even though the official ROS2 package index folder contains multiple diagnostic packages , they are not related to UDS.
Log and Trace
Log and Trace in AAS provides APIs to log and trace applications. The resulting information is categorized according to severity levels and can be linked to different cases, e.g., safety and security topics. For ROS2, there are packages for logging and tracing available. Most of them are not part of the binary packages but can be integrated as needed. The tracing package enables the recording of runtime and execution data, system and component behavior, and analysis thereof.
Cryptography
AAS crypto interfaces support includes random number generation, the Advanced Encryption Standard, asymmetric encryption Rivest–Shamir–Adleman (RSA), hash functions, Media-Access-Control-Address (MAC), and key exchange mechanisms. AUTOSAR also supports the handling of cryptographic objects, e.g. X.509 Certificates. The security features of ROS2 are based on the security plug-in of the DDS standard. It uses the Advanced Encryption Standard. The Public Key Infrastructure handles encryption, decryption, signing, and hashing. As all security features of DDS are disabled by default, the user must enable them via the ROS2 security tool. Both AAS and ROS2 offer the same functionalities, but for ROS2 manually activation is required.
Network management
The AAS Network Management manages the transition of operation, sleep mode and shutdown of network components. For ROS2 there is no specific network API for coordinating bus communication, but the QoS policies also specify the liveliness of nodes according to communication transmitted and other communication related activities. The Network Management of AAS is an example for the very detailed specification of AUTOSAR APIs, while in ROS2 the functionality may be set up by combining several concepts and packages.
Update and Configuration Management
The Update and Configuration Management of AAS is the interface handling update requests, the update itself and software modification. It is responsible for realizing updates Over The Air (OTA) and combines the installation and update process with removal and track record of SW components. It also enables variant-specific configuration and validation of functionality and all other processes after the update. In ROS2, there are two packages for Continuous Integration (CI) and continuous development. The Pull Request (PR) builds package runs and tests a package whenever a PR occurs. It is limited to Linux and to does not work across repositories. To make up for these limitations, the CI builds package exists. In contrast to PR builds, it does not run and test automatically and its testing activity is not limited to the updated component but does test all packages on every platform. It is also possible to limit the test scope for time-related reasons. For updating functionality, the package maintainers must constantly do a package release. In total, the functionality seems to be comparable to the Adaptive AUTOSAR service.
Even though specification is removed from AAS R22-11, lets evaluate RESTful as well.
RESTful
AAS Representational State Transfer (RESTful) API package provides a web service-based communication option. A RESTful API is typically characterized by dynamic data in combination with a Unified Resource Identifier (URI), processing its data asynchronously. For the implementation of RESTful APIs, a dedicated ROS2 package could not be found. However, there is the ROSTful package available for ROS version Indigo or Kinetic. If and when this will be ported as ROS2 package cannot be anticipated. An alternative way to realize asynchronous data processing in ROS2 are actions. They can be called by a client similar to a remote procedure call and thereby passing over multiple data arguments. The action then processes the data and executes a callback once it’s finalized. Even though an action is similar to an Adaptive AUTOSAR RESTful API, it is not the same, and ROS2 does not entirely fulfil the RESTful API characteristics.
Why ROS?
One of the main differences between these platforms is that the software of AUTOSAR is not open-source. License fees apply and also AUTOSAR-licensed tools are not available free of charge. In contrast, the ROS libraries and related documentation are open-source and the developer community provides additional packages and code bases that can be individually modified. Then again, there are ROS2 based solutions available that are not open source. In short ROS2 is open source and neither a membership nor license fees apply. AAS is specifically tailored to the trend toward Service Oriented Architecture(SOA) in automotive, the initial scope of the open-source ROS2 were robot applications. AAS is more standardized than ROS2, also providing development process standards. It serves interoperability and consistent specifications within the industry. The platform satisfies automotive requirements, especially regarding security innately. Some of the Adaptive AUTOSAR APIs and service functionality can be completely fulfilled by ROS2. The safety certification of a ROS2 based commercial version (like ROS based APEX OS) showed that it can be made automotive SOA-compliant by adapting and designing it accordingly. This explicitly refers to the enhancement of real-time capabilities and memory management by rewriting parts of the open-source implementation. In contrast to Adaptive Autosar, it may be barrier-free for new adopters to start using the platform in architecture development.
Do you see a bright scope for ROS in automotive sector? Will the effort of tailoring ROS for automotive requirements overweigh the ease of access and usage? Let me know your thoughts…
About the Author :
Ms. Shalini. K
Senior Technical Specialist,
Elektrobit India
Ms. Shalini.K is an Automotive and Embedded enthusiast.
Ms. Shalini.K completed Masters in VLSI and embedded systems and have profound experience in Autosar. Love to harness technical excellence and learn more!
Going with Da Vinci, Learning is the only thing the mind never exhausts, never fears, and never regrets.
Ms. Shalini.K can be contacted at :
Also read Ms. Shalini.K earlier article:
 is an open-source robotics middleware suite. Although ROS is not an operating system, it is a set of software...){kind=link}