{"id":4178,"date":"2020-06-29T08:51:59","date_gmt":"2020-06-29T06:51:59","guid":{"rendered":"https:\/\/zen-cori.138-201-132-86.plesk.page\/?p=4178"},"modified":"2022-09-19T17:24:27","modified_gmt":"2022-09-19T15:24:27","slug":"autosar-architecture-what-every-function-developer-should-know","status":"publish","type":"post","link":"https:\/\/www.btc-embedded.com\/de\/autosar-architecture-what-every-function-developer-should-know\/","title":{"rendered":"AUTOSAR \u2013 What Every Function Developer Should Know\u2026"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In recent decades, the demands for designing smarter and safer vehicles has caused a significant increase in the size and complexity of the automotive systems software. In a modern high-end passenger car, more than 100 million software lines of code (SLoC) are embedded and distributed across as many as 80 ECUs communicating in a network infrastructure. In terms of SLoC, automobile code size is second only to Google’s internet services (2billions SLoC). This makes the modern passenger car one of the most complex systems being developed today. To effectively address this complexity while improving the efficiency and quality of automotive software, OEMs (Original Equipment Manufacturer) and suppliers formed a consortium back in 2003 to create AUTOSAR (AUTOmotive Open Software Architecture<\/a>) as an integrated standard for vehicle software development. The first AUTOSAR architecture version was released in 2006. It\u2019s now called AUTOSAR Classic and in 2017 another AUTOSAR standard (Adaptive) was created to address connected vehicles and autonomous driving applications.<\/p>

In this article, we\u2019ll explain how AUTOSAR Classic helps to deal with software complexity and introduce the main AUTOSAR concepts and terminologies the function developer should know.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Introduction to AUTOSAR Architecture Classic<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Automotive systems are often developed in a collaborative effort between OEMs and suppliers. Suppliers develop subsystems specified by the OEM or develop their own subsystem that they sell as an \u201coff-the-shelf\u201d product. Before AUTOSAR, the collaboration relied on specification languages defined within the OEM-Supplier partnership. A new partnership began with an agreement on a new specification language, and integrating a proprietary supplier component required adaptation efforts. With the growing demand of new vehicle functions and the expansion into several domains, the old collaboration approach became impractical.\u00a0 Distributed functionalities in the vehicle architecture also added complexity. AUTOSAR architecture was created to make this complexity manageable, by providing a system-based design environment for the development teams creating the software architecture.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Modular architecture and virtual communication bus<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

To manage the complexity, AUTOSAR introduced a modular architecture with layers to separate hardware-independent application software from hardware-oriented software.<\/p>

  • The upper layer,\u00a0Application Software (ASW)<\/strong>\u00a0hosts the application functions as individual software components (SWC).<\/li>
  • The lower layer, the\u00a0Basic Software (BSW)<\/strong>\u00a0includes low level software like services and hardware specific software.<\/li>
  • Between these layers is an abstraction layer called the\u00a0Runtime Environment (RTE)<\/strong>\u00a0that manages the interface between the two other layers.<\/li><\/ul>
    \u00a0<\/div>

    The AUTOSAR architecture also provides a way to decouple the applications from the hardware infrastructure. AUTOSAR introduced the concept of Virtual Functional Bus (VFB) which makes it possible for the SWCs to interact independently from where they are executed in the system (inside one ECU or on different ECUs). \u00a0As SWCs are allocated to the various ECUs, the virtual connections are mapped to local connections (intra-ECU) or onto network communication technologies such as CAN or FlexRay (inter-ECUs). The connection mapping is implemented by the RTE and becomes the concrete interface between individual SWCs and also between SWCs and the BSW (the RTE implements the VFB on a specific ECU).<\/p>

    With the VFB, OEMs and suppliers can develop multi-domains and competitive software without detailed knowledge on the lower-level technologies or dependencies. It gives the flexibility to scale the overall system afterwards (e.g. number of ECUs, ECU-to-Application mapping, network technology, etc.). It enables the reusability and transferability of software components and makes it easier to add new functions to the system. Moreover, the VFB validates all plausible communication between SWCs, which will detect any software architecture errors and improve the software architecture quality.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t

    AUTOSAR Architecture - Application Software Layer<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    An AUTOSAR application consists of several software components interacting together.<\/p>

    Hierarchical architecture<\/h4>

    The Application software layer offers a hierarchical structure to create the software components:<\/p>