| Type: Description:Valid | AUTOSAR shall provide a software platform called AUTOSAR Classic Platform, which targets the domain of real-time systems. Rationale: Real time systems are divided into hard and soft real time systems. Hard real time systems always have to deliver the correct result in the given time whereas from soft real time systems it is demanded that they compute the correct answer in a given time in a dedicated average.Use Case:Drive and brake by wire systems |
| Applies to:CP Dependencies:-- Supporting Material:-- |
| Type: Description:Valid | As the interface definition for applications is a prerequisite for reuse of software AUTOSAR shall provide such a standardized interface. | Rationale:From an application point of view the interface to other AUTOSAR Application Software of one AUTOSAR Platform shall be identical, independent whether the Application Software is located on the same or on another ECU.Application Software development independent from the underlying communication system. |
| Applies to:AP, CP Dependencies:-- Supporting Material:-- |
| Type: Description:Valid | AUTOSAR shall provide an abstraction from hardware characteristics. This abstraction shall only be accessible to |
| Type:Draft Description: | AUTOSAR shall provide a means to abstractly model the vehicle VFB, independent of Classic, Adaptive of Non-AUTOSAR platforms. Rationale:To enable pure design of vehicle VFB communications – whilst allowing deferral of platform (Classic, Adaptive, Offboard) selection Use Case:Separation of views on the system Requirement decomposition and traceability Functional derivation and traceability |
| Applies to:CP, AP, FO Dependencies:RS_Main_00080, RS_Main_00161, RS_Main_00507 Supporting Material:Draft |
| Type:Valid Description: | AUTOSAR shall support the development of Application Software independent from the implemented communication protocol. Rationale:Independency from the underlying communication protocol is a prerequisite to support the reallocation of Application Software across ECUs that belong to the same Platform type. Use Case:Reallocation of Application Software from ECU A with CAN communication to ECU B with FlexRay communication. |
| Applies to:CP, AP, FO Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall support E/E architecture with different in-vehicle network technologies. Interconnection of these networks via gateways, bridges, or repeaters shall be supported. Rationale:ECUs communicate via different communication systems. Use Case:Support of today's network topologies of E/E-architectures in series production. |
| Applies to:CP, AP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall support diagnostic standards (OBD and ISO14229) and communication protocols (UDS) to allow diagnostic access to the ECUs. Rationale:Standardized diagnostic access is required for field service and admission. Use Case:Perform diagnosis of Application Software or ECUs during maintenance of the car. |
| Applies to:AP, CP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall support the communication between platforms defined by AUTOSAR and platforms defined by other parties. Rationale:Automotive networks consist of multiple communication partners which are placed both in ECUs inside the vehicle and offboard systems outside of the vehicle. They are running different software platforms, defined by |
| Type:Valid Description: | AUTOSAR shall provide a method to configure mode management mechanisms for Application Software to control or react on modes of the ECU or vehicle. Rationale:The behavior of Application Software highly depends on the overall mode of the ECU. Therefore the method of mode management has to be standardized to achieve the same behavior if Application Software is allocated on another ECU. Use Case:Degradation of application functionality in certain power modes. |
| Applies to:AP, CP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall provide a unified way to monitor, distribute or store application-internal information at runtime. This shall be possible without knowing anything about the ECU internal memory usage/addressing. Rationale:For development purpose additional meta information about the current status or current variable values of an application might be needed. Use Case:Provide current values of application-internal variables, provide information of the current state of an application's state machine. |
| Applies to:AP, CP Dependencies:-- |
| Type:Valid Description: | AUTOSAR shall provide means to check data authenticity, data integrity, optionally confidentiality and data freshness in inter ECU communication. Rationale:Dependable systems rely on authentic and trustworthy exchange of information between ECUs. Protecting and assuring data authenticity, data integrity and data freshness in inter ECU communication allows for the development of secure and safe systems by using the AUTOSAR platform. Confidentiality ensures privacy of data. Use Case:Protection of on-board communication against manipulation or eavesdropping. |
| Applies to:AP, CP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR communication shall support intra ECU communication. Rationale:A SWC should be able to communicate with each another SWC within the same ECU. Use Case:Several SWCs send signals to each other to exchange algorithm data. |
| Applies to:CP, AP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall support the translation between signal-based and service-oriented communication. Rationale:Adaptive Platform restricts communication to Service-oriented communication, the rest of the vehicle however still |
| Type:Draft Description: | AUTOSAR shall be compliant to the UDS session layer as defined in ISO 14229-2. Rationale:The diagnostic in AUTOSAR shall be the central service handler for UDS diagnostics Use Case:Interaction with UDS compliant tester. |
| Applies to:CP, AP, FO Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR Platforms shall support commonly used safety mechanisms. This includes but is not limited to: · Mechanisms to ensure freedom of interference for Adaptive Applications, Functional Cluster, Software Components and Basic Software Modules · Safe inter ECU communication · Measures to implement fail operational systems · Templates to support the configuration and documentation of safety relevant aspects However, it cannot ensure safety for systems. This is to be ensured on system level. Rationale:Facilitate the development of safety related systems by using |
| Use Case:Driver temporarily/partially passes responsibility for driving task to vehicle (ADAS/HAD) OEM provides safety or security related software for installation onto vehicle High availability, fail-operational systems |
| Applies to: Dependencies: Supporting Material:CP, AP -- -- |
| Type:Valid Description: | AUTOSAR shall provide mechanisms for error handling in order to support the development of reliable systems. Rationale:Reliability is one of the important characteristics to achieve safety. Use Case:Reduction of repair time of a vehicle in field service. |
| Applies to:CP, AP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | Availability of the Adaptive Platform is defined as the probability that platform services will operate satisfactorily at a given point in time. It excludes both preventive and corrective maintenance downtime. Availability is limited to normal runtime behavior (excluding e.g. software update) Rationale:Facilitate the development of highly available systems by using AUTOSAR platforms. Use Case:Highly available systems are required for automated driving applications. |
| Applies to:AP, CP Dependencies:-- Supporting Material:-- |
| Type: Description:Valid | To develop safety related automotive systems all processes applied need to follow the corresponding requirements given in ISO26262. AUTOSAR shall support development processes for safety related systems by providing according exchange formats (e.g. for requirements tracing) and concepts. Rationale:Automotive software is in many cases safety related. Therefore dedicated development processes have to be followed. AUTOSAR shall support the users to apply these standards | Use Case: Applies to: Dependencies: Supporting Material:Development of brake assist, highly automated drivingAP, CP, FO--ISO26262 |
| Type:Valid Description: | AUTOSAR shall provide a formal description of Application Software for the Adaptive Platform as well as the Classic Platform. This description together with source code and/or object code forms an AUTOSAR Application Software. Rationale:Software reuse is one of the major aims of AUTOSAR. | Use Case: Applies to: Dependencies: Supporting Material:Momentum control in different ECUs.AP, CP, FO---- |
| Type: Description:Valid | AUTOSAR shall provide specified test cases and the essential test methodology to ensure interoperability on application (RTE side) and bus level for BSW on ICC1 level (Black Box Test). These specified test cases and its related methodology shall be developed to test implementations of AUTOSAR basic software. |
| Rationale:Acceptance tests are strongly needed to provide evidence that a product complies with the AUTOSAR specification i.e. to ensure a certain behavior of the regarded elements at the interfaces to application and communication busses. Use Case:Integration of the infrastructure SW into a specific ECU, bring it into the E/E- architecture without backlashes on the system. Example from real world: Integration of BSW stack (ICC1 level) to applications and the ECU infrastructure without difficulties. Support test of any ICC implementations (from ICC1 to ICC3). Reuse of the same test specification even when the ICC3 specification details change | |
| Applies to:TC Dependencies:-- Supporting Material:-- Tested Items:-- |
| Type:Valid Description: | As test cases are executed on implementation level they limit a possible generic verification by partners. Rationale:AUTOSAR test cases should create an implementation space that is includes a possible solution. Use Case:Testability should be independent from the partners implementation. |
| Applies to:TC Dependencies:-- Supporting Material:-- Tested Items:-- |
| Type:Valid Description: | Well-defined interfaces are the key for exchangeability, reusability and the basis for the freedom of interference. Decomposition on interface level is essential for an appropriate clustering and partitioning in the AUTOSAR Application Software. Rationale:Principle: "divide and conquer" which is a key success factor in the development of large systems. Use Case:Development of large interconnected software systems with |
| Applies to:AP, CP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | A comprehensive software model shall capture all elements of a distributed software system. The definition of functionality shall be independent from the final assignment to platforms and ECUs. Rationale:The allocation of software to platforms shall be a subsequent step after the overall definition of functionality. Use Case:Development of large software systems being deployed on mixed platforms. |
| Applies to:CP, AP, FO Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | Reuse of existing legacy software shall be supported by AUTOSAR. Integration of legacy software in an ECU compliant to AUTOSAR shall be supported. Rationale:Independent of the target the code has to be compatible to legacy implementation on protocol level. Use Case:Reuse of existing driver software for a new ECU that is developed according to AUTOSAR. Communication with non-AUTOSAR software systems. |
| Applies to:CP, AP, FO Dependencies:-- Supporting Material:-- |
| Type:Valid |
| Description: | AUTOSAR specifications shall allow efficient implementations with respect to • RAM • ROM, Flash • Computing Power • Bus bandwidth |
| Rationale: | Limited resources like flash, RAM, computing power characterize automotive microcontrollers. |
| Use Case: | Integration of the AUTOSAR platform and a single application in a typical 16-bit automotive microcontroller. |
| Applies to: | CP |
| Dependencies: | -- |
| Supporting Material: | -- |
| Type:Valid Description: | The definition and description of roles and activities in the design methodology should support a work-share model. Rationale:As AUTOSAR enables work-share on different positions and activities it shall provide a common understanding of roles and activities. Use Case:Share activities like AUTOSAR configuration and Application Software partitioning between software integrator and software architect. |
| Applies to:AP, CP, FO Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall support the work-share in large development projects via well-defined exchange formats. Rationale:A typical AUTOSAR system is expected to carry a huge number of signals per vehicle. To develop vehicle descriptions a good organization of work-share is needed. To support such organizations, well defined concepts for information exchange are required. Use Case:Data sharing between OEM and 1st Tier supplier. |
| Applies to:AP, CP, FO |
| Type: Description:Valid | In AUTOSAR it shall be possible to describe all requirements of Application Software to their platform environment. This enables the integrator to provide the Application Software in such an environment on an ECU. Rationale:The AUTOSAR format will include system, ECU and SW specification and is necessary for the ECU integration process. Use Case:OEM designs an Application Software and a Supplier will integrate these AUTOSAR Software Applications on an ECU. |
| Applies to:AP, CP, FO Dependencies:-- Supporting Material:-- |
| Type: Description:Valid | AUTOSAR shall support observation, assessment and methodology of timing requirements throughout the development cycle. Rationale:Application Software has specific timing requirements which have to follow the common methodology in order to provide reliable and comparable information towards timing. Use Case:Real time control of today's gasoline injection system. |
| Applies to:AP, CP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | To achieve safety-related properties an adequate software architectural design and implementation matching the safety |
| Rationale: | In the context of the safety-related developments a confirmation that design and implementation are adequately safe is required. |
| Use Case: | -- |
| Applies to: | AP, CP, FO |
| Dependencies: | -- |
| Supporting Material: | ISO26262 |
| Type: Description:Valid | Variant management is introduced on vehicle level and is required to check compatibility of Application Software in different vehicle versions and release states. Rationale:In today's automotive development and production it is possible to reach many different variants for one vehicle platform. This also affects the AUTOSAR Application Software variants. Use Case:Integration of Application Software on different ECUs and/or E/E-architectures. |
| Applies to:AP, CP, FO Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall support the testability of compliant implementations and tools. Rationale:Testing of implementations is required by software development, software maturity and software safety standards. Use Case:Tool interoperability tests and/or test of AUTOSAR Basic Software implementations. |
| Applies to:AP, CP, TC Dependencies:-- Supporting Material:ISO26262 |
| Type:Valid Description: | AUTOSAR shall define naming conventions for internal and external symbols created and used by the standard. Rationale:Naming conventions shall be defined in specification documents to achieve a standardized and consistent documentation. This is good documentary practice, helps for better understanding, reduces ambiguities and improves cooperation Use Case:Work-share models between OEM and supplier. Development of AUTOSAR specifications. |
| Applies to:AP, CP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall reflect the stages of a software development process and define templates how information at these stages can be exchanged between the different parties. As blueprint for such development processes AUTOSAR shall consider existing standards like ISO26262 and Automotive SPICE. Rationale:During the development of a vehicle, software system at different process steps information is exchanged between the various partners. AUTOSAR shall refine the formats and state criteria for completeness of the exchanged information to capture general requirements on the progress of development. Use Case:OEM provides safety or security related software for installation onto vehicle OEM provides additional QM software for installation onto vehicle Developer performs agile development of vehicle functions Methodology and exchange formats |
| Applies to:AP, CP, FO Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall specify an automotive security approach defining security mechanisms and properties. Rationale:The security properties which shall be supported by AUTOSAR include authenticity, confidentiality, integrity and non-repudiation. Use Case:Protect after sales feature activation and data usage via appropriate security mechanisms. Manage initialization, derivation and distribution of cryptographic material. Store security related events for on-board and off-board forensic analysis. |
| Applies to:CP, AP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall provide a software platform called AUTOSAR Adaptive Platform, which targets the domain of automotive applications with high demands regarding computing power and memory. Rationale:Advanced automotive applications require a huge amount of ressources (computing power and memory). To develop efficiently such systems a software platform with different characteristics as required for RS_Main_00001 is required e.g. different scheduling strategies, dynamic memory management etc. Use Case:Development of applications for automated driving and advanced driving assistance systems |
| Applies to:AP, FO Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall provide a software architecture, which distinguishes between Application Software, a Runtime Environment and Basic Software. Rationale:The Runtime Environment defines a standardized programming interface for the Application Software. This enables the reallocation and reuse of Software Components. Use Case:Relocation of yaw rate control from one ECU to another. |
| Applies to:CP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall develop means to enable reallocation of AUTOSAR Application Software at the following points in time: ·Design-time: During development of the ECUs (AP, CP) ·Run-time: Time between start-up and shut-down of the software stack (AP) ·Life-time: Time after start of production (AP, CP) Rationale:Enable the reallocation of Application Software to different ECUs. Use Case:·OEM provides safety or security related software for installation onto vehicle ·OEM provides additional QM software for installation onto vehicle ·Developer performs agile development of vehicle functions ·Reallocation of yaw rate control from one ECU to another at development-time ·Optimization of overall system architecture. ·Update of (single) Adaptive Application or update of specific configurations over the air |
| Applies to:AP, CP (with limitation) Dependencies:RS_Main_00140, RS_Main_00141 Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall support the development of Application Software by providing standardized libraries with commonly used functions. Rationale:Share routines between different Applications. Use of optimized routines by Applications integrated in different ECUs. Relocation of SW component from ECU A to ECU B with a different microcontroller. |
| Applies to:CP, AP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | In engineering, redundancy is the duplication of critical components or functionalities of a system with the intention of increasing reliability of the system. AUTOSAR shall support the freedom of interference according to ISO26262. Rationale:Use-Cases like highly automated driving require a high system reliability. Use Case:Driver temporarily/partially passes responsibility for driving task to vehicle. |
| Applies to:AP, CP Dependencies:ISO26262 Supporting Material:http://en.wikipedia.org/wiki/Redundancy (engineering) http://en.wikipedia.org/wiki/Active redundancy |
| Type:Valid Description: | AUTOSAR shall support virtualization in a way that it can be hosted and executed as a guest operating system in a virtualized environment. Rationale:It shall be possible to run AUTOSAR on top of existing |
| Use Case: | Development of ECUs which contain infotainment as well as control functionality |
| Applies to: | CP, AP |
| Dependencies: | -- |
| Supporting Material: | -- |
| Type:Valid Description: | The different solutions for basic software functionalities shall be consolidated to a single standard. Whenever possible AUTOSAR shall make use of existing standards provided that they meet the given requirements. Rationale:Historically, OEMs and the major Tier1 suppliers have created proprietary standard core solutions, with partly different functionality. To achieve a common standard, which is accepted and used by all of the participating partners these solutions shall be consolidated by AUTOSAR. If an agreed common solution supported by OEMs and Tier 1 already exists, this solution shall be adopted by AUTOSAR in order to ease reuse of existing software. Use Case:Operating System in AUTOSAR ECUs. Partial Networking. Network Management. POSIX |
| Applies to:CP, AP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | An important software functionality is the access to non-volatile memory. AUTOSAR shall support read and write access to non-volatile memory. Rationale:Application Software needs to store data, which is available after a restart. Use Case:Storage of error codes |
| Applies to:AP, CP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | The AUTOSAR platforms shall support access to crypto and security related Hardware and define Software to access those. Rationale:Software Components need to encrypt, authenticate and store data in a secure memory for protection against malicious entities. Use Case:Security |
| Applies to:AP, CP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall provide secured access to ECU data and services by secure authentication of external ECU users. For this mechanisms access control decisions need to be enforced. Rationale:Secure access and authentication mechanisms are required for prevention of unauthorized access. Use Case:Secure V2X connection |
| Applies to:AP, CP Dependencies:To fulfill this requirement it is also necessary that the environment that is not standardized by AUTOSAR (e.g. bootloader) matches the same security requirements. Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall support standardized up- and download of data and software. For all kind of data exchange between off- and onboard artifacts mechanisms and methods shall be defined. These mechanisms and methods shall support common protocols used for data-transfer. Partial updates of the software shall be supported. Independent access control rules and policies apply. Rationale:Up- and download of data and software is required for software updates using standardized mechanisms. Use Case:Download of dedicated Software Components in ECU. |
| Applies to:AP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall provide a unified way for off- and onboard data calibration. The calibration data shall be accessible by Applications. |
| Type:Valid Description: | The middleware shall support high speed and high bandwidth communication between executed SW. Rationale:Requirements for communication speed and bandwidth have grown at a rapid pace in the past and continue to grow at an unbroken rate. Use Case:High-bandwidth data like image or sensor data is exchanged between components within automotive networks. |
| Applies to:CP, AP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall support service-oriented communication between applications independently of the location of the applications. Rationale:Reuseability of services and dynamic configuration of communication paths. Use Case:A parking assistant application wants to use camera and radar services. |
| Applies to:AP Dependencies:RS_Main_00150, RS_Main_00140 Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall support data-oriented communication between applications. This means that applications are able to send data to all applications configured to receive the respective data. Rationale:Transfer data to applications on other ECUs or on the same ECU. Use Case:Send current vehicle speed over CAN bus to various |
| Applies to: | CP, AP |
| Dependencies: | RS_Main_00150, RS_Main_00140 |
| Supporting Material: | -- |
| Type:Draft Description: | Each AUTOSAR module shall provide a standardized method and interface to enable debugging the software of AUTOSAR systems with awareness of the AUTOSAR architecture. Each part of the AUTOSAR software shall provide methods of obtaining internal state information to be used by debuggers. Rationale:Debugging tools need internal information to visualize the state of the software. Components and modules implementing this requirement shall provide the necessary state information that can be used by internal and external tools. Use Case:Debugging the software. |
| Applies to:CP, AP Dependencies:-- Supporting Material:-- |
| Type:Draft Description: | Each AUTOSAR module shall provide a standardized method and interface to enable tracing and profiling the software of AUTOSAR systems with awareness of the AUTOSAR architecture. Each part of the AUTOSAR software shall provide methods of obtaining event information to be used by trace analysis tools. Rationale:Tracing and timing analysis tools need internal information to visualize and inspect the run-time behavior of the software. Components and modules implementing this requirement shall provide the necessary details and hooks that can be used by tools. Use Case:Run-time tracing the software, profiling, timing measurement. |
| Applies to:CP, AP Dependencies:-- |
| Type:Valid Description: | The AUTOSAR Adaptive Platform shall support the implementation of Application Software in different programming languages. Rationale:Depending on the context and domain of a development project different programming languages might be appropriate. AUTOSAR shall support a variety of programming languages. Use Case:Implementation of complex algorithms in C++ Implementation of safety relevant functionality in C |
| Applies to:AP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | Advanced systems require dynamic allocation of AUTOSAR Applications and adaptations of the communication topology after development and production at life-time of the system AUTOSAR shall provide a technical possibility which provides these Software changes at runtime. Rationale:Advanced driving assistance functions have to be updated (e.g. after development or production). Use Case:Update of Application Software or update of configuration over the air |
| Applies to:AP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR communication shall support standards for wireless off-board communication. Rationale:To be compatible with off-board service providers, the AUTOSAR communication needs to support off-board |
| Use Case: | Services for automotive applications can be provided in cloud instances or vehicle backend |
| Applies to: | AP |
| Dependencies: | -- |
| Supporting Material: | -- |
| Type:Valid Description: | AUTOSAR communication shall provide secure communication with off-board entities. Rationale:Data should be securely transferred between the vehicle and off-board entities to protect data integrity, privacy and prevent misuse. Use Case:Purchasing applications or unlocking functionality through the headunit HMI should be safe and secure. |
| Applies to:AP, CP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR communication shall establish communication paths dynamically. Rationale:The deployment of services can depend on many factors, changing several times during the development process or after release in the field. Use Case:A service is selected based on availability of sensor data. |
| Applies to:AP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR communication shall assure quality of service on communication |
| Rationale: | Some applications are sensitive to delays in signal reception. Other applications may need guaranteed reception of certain signals for proper operation. |
| Use Case: | An algorithm in the ESP needs data from the wheel sensors with low-latency and guaranteed reception. |
| Applies to: | AP |
| Dependencies: | -- |
| Supporting Material: | -- |
| Type:Valid Description: | The middleware shall provide an execution framework for adaptive SWCs. Rationale:SWCs can be started and stopped based on application logic. To support this, the execution management should be able to facilitate lifecycle operations for numerous SWCs. Use Case:The execution management starts all required SWCs at system initialization. |
| Applies to:AP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall provide an Execution Framework towards applications to implement concurrent application internal control flows. Rationale:The execution framework must manage numerous running SWCs and handle their independent control flows. Use Case:The execution framework starts several SWCs in an ordered manner. |
| Applies to:AP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | It shall be possible to extend AUTOSAR with new SWCs without recompiling the platform foundation Rationale:To prevent unnecessary build time, individual SWCs should be able to be compiled independently without the need to recompile all other system software. Use Case:A new SWC is introduced to an ECU implementation at a later point in time during the SW project. |
| Applies to:AP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall provide a complete functional specification of the Basic Software including interfaces and behavioral description. Rationale:To support reallocation of Software Components it is necessary that the Software Components can rely on identical services provided by the Basic Software. The Basic Software is a necessary stable foundation for implementing applications on multiple ECUs. Use Case:Application Software shall be useable on multiple implementations of the Basic Software. |
| Applies to:CP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR ECUs shall support common established communication systems. This includes at least but is not restricted to: CAN, LIN, FlexRay, Ethernet Rationale:Automotive ECUs communicate over different standardized communication systems. These shall be supported by AUTOSAR. Use Case:Implementation of distributed functionality e. g. driving assistance systems |
| Applies to:CP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall support hardware features of commonly used automotive microcontrollers. Rationale:Automotive ECUs use dedicated, highly integrated microcontrollers, which have to pass automotive qualification procedures. The AUTOSAR shall support the integrated features of these microcontrollers. These include, but are not limited to: Digital I/O Analog/Digital converter Pulse-width modulation Bus controllers for CAN, LIN, FlexRay, Ethernet Multiprocessor architectures Many core architectures Memory protection units Flash Microprocessors Use Case:Development of typical automotive control units [UC_AD1.4] Highly Automated Driving |
| Applies to:CP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | The AUTOSAR Basic Software shall support access to general purpose I/O. Rationale:Software Components need to access application specific hardware (sensor and actuators) Use Case:Temperature sensor for engine control. |
| Applies to:CP Dependencies:-- Supporting Material:-- |
| Type:Draft Description: | AUTOSAR shall support direct forwarding of CAN, LIN, and FlexRay frames from multiple source buses to a destination CAN or FlexRay bus, to Ethernet, or to a proprietary network (CDD). The destination can be a diagnostic connector (CAN(-FD) or Ethernet/DolP), an intermediate bus, or a CDD that represents a special bus or a bus controlled by a non-AUTOSAR application. The following forwardings shall be supported: • LIN/CAN -> CAN • LIN/CAN/CAN-FD -> CAN-FD • LIN/CAN/CAN-FD/FlexRay -> FlexRay • LIN/CAN/CAN-FD/FlexRay -> Ethernet • LIN/CAN/CAN-FD/FlexRay -> CDD Rationale:It is not always possible or sometimes just too complicated to connect an analysis tool directly to an internal network. Forwarding of internal communication to a diagnostic connector allows for observation of internal communication using an external tester. Use Case:Debugging of internal networks without direct access from an analysis tool. |
| Applies to:CP Dependencies:-- Supporting Material:Concept 634 "Bus Mirroring" |
| Type:Valid Description: | Integration of software of different suppliers requires exchange of software (especially source code) between the different parties involved. Thus, AUTOSAR shall provide mechanisms to safeguard software. AUTOSAR shall ensure a smooth integration process that at the same time protects intellectual property of the companies involved. Rationale:Integration of third party solutions requires dealing with intellectual property issues. Use Case:1) SW sale of split-screen software for navigation. 2) Integration of BSW modules of different suppliers. |
| Applies to:AP, CP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall support the work-share in large development projects via the definition of common data exchange points and profiles which provide guidance with respect to completeness and correctness of data at these data exchange points. Rationale:Smooth exchange of data between different stakeholders by improved tool interoperability. Avoid iterations due to incomplete data. Clear definition of a data exchange point for all stakeholders. Early identification of possible data exchange problems. Use Case:Data sharing between OEM and 1st Tier supplier. |
| Applies to:AP, CP, FO Dependencies:RS_Main_00300, RS_Main_00250, RS_Main_00251 Supporting Material:-- |
| Type:Valid Description: | AUTOSAR shall provide means to structure Application Software in a hierarchical way, so that only links to outside Software need to be treated / adapted / changed in the next hierarchical level. Rationale:Objective is to allow each actor in the development chain to focus on the required level and tasks. Use Case:Software development of an engine management system can only be achieved by using hierarchical strategies. |
| Applies to:AP, CP, FO Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | Migration from AUTOSAR release n to release n+1 shall be supported. AUTOSAR shall provide migration strategies, how Software Components and ECUs of different release have to be adapted to interoperate. Rationale:Compatibility ensures a long time usage of the AUTOSAR standard. Use Case:Integration of ECU's using infrastructure software of the latest AUTOSAR release in a network built from ECU's using a former release. |
| Applies to:AP, CP Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | In order to avoid redundant test cycles and ease the reuse of test results for users of AUTOSAR standard, acceptance tests shall focus on reduction of test effort and test costs. Test concept shall address explicitly efficiency. Rationale:Users of acceptance tests will typically use these tests for checking that a BSW implementation is mature enough to enter the user's ECU software development process. Within this development process, there are usually more in-depth release tests in place. The acceptance tests are thus not required to test the BSW in full depth and with full coverage and can therefore not replace release tests at OEMs or Tier1s. Standard test ease the reuse of test results because they are commonly understood by different market partners (who use the test results / who implement the tests and who execute the tests). Use Case:BSW handover into Development process Selection of the standard tests needed for an application (where test results are required) / documentation of the standard test supported by a BSW implementation (where test results will be provided) |
| Applies to:TC Dependencies:-- Supporting Material:-- Tested Items:-- |
| Type:Valid Description: | Acceptance tests shall ensure interoperability of BSW implementations of one AUTOSAR release in one vehicle network Rationale:Sourcing and differences in lifecycles of ECUs require flexibility in the choice of BSW implementations Use Case:Heterogenic vehicle networks of ECUs with different BSW implementations of the same AUTOSAR release |
| Applies to:TC Dependencies:-- Supporting Material:-- Tested Items:RS_Main_00230, RS_Main_00430, RS_Main_00260, RS_Main_00160, RS_Main_00360 |
| Type:Valid Description: | Acceptance tests shall test interoperability of BSW implementations in vehicle networks. Rationale:BSW is supplied from various sources and suppliers Use Case:heterogenic vehicle networks of ECUs from different suppliers and gateways |
| Applies to:TC Dependencies:-- Supporting Material:-- Tested Items:RS_Main_00210, RS_Main_00230, RS_Main_00430, RS_Main_00260, RS_Main_00160, RS_Main_00360, RS_Main_00270 |
| Type:Valid Description: | Acceptance tests shall test interoperability of BSW implementations to applications. Rationale:Application development must be independent from the different BSW implementations. The application interfaces are the RTE with its interfaces and the BSW services. Use Case:Strategic, abstract and generic application development Support for different development cycles for applications and BSW implementations |
| Applies to:TC Dependencies:-- Supporting Material:-- Tested Items:RS_Main_00400, RS_Main_00150, RS_Main_00060, RS_Main_00410, RS_Main_00440, RS_Main_00460, RS_Main_00260, RS_Main_00160, RS_Main_00080, RS_Main_00320 |
| Type:Valid Description: | Acceptance tests shall provide a reference to measure maturity. Rationale:An existing test specification provides verification for requirements that are available with the AUTOSAR software standard. A common set of test cases as a reference enables the verification in the software implementation. Use Case:Reuse of standard tests during the qualification process of BSW implementation. |
| Applies to:TC Dependencies:-- Supporting Material:-- Tested Items:-- |
| Type:Valid Description: | Acceptance tests shall cover a commonly agreed subset of AUTOSAR requirements. Rationale:By definition acceptance tests are designed from user perspective, the user decides to accept the BSW for further usage in projects. The configurability of AUTOSAR requires focusing on the most used features. Use Case:Specification and implementation effort focussed on the features or test cases with the highest market needs |
| Applies to:TC Dependencies:-- Supporting Material:-- Tested Items:-- |
| Type:Valid Description: | To develop safety related automotive systems all processes applied need to follow the corresponding requirements given in ISO26262. Accordingly the applicable process related requirements of ISO26262 have to be fulfilled by AUTOSAR processes. Rationale:AUTOSAR shall support the development of systems according to the highest ASIL. Use Case:Development of safety related automotive systems, e.g. to achieve high availability and fail-operational systems for highly automated driving |
| Applies to:AP, CP Dependencies:-- Supporting Material:ISO26262 |
| Type:Valid Description: | The AUTOSAR platforms shall support a time synchronization of ECUs with multiple timebases over automotive communication busses. Rationale:A synchronized time between the ECUs in a vehicle is necessary. Use Case:Time synchronized applications, vehicle-wide synchronized logging and sensor fusion |
| Applies to:AP, CP, FO Dependencies:-- Supporting Material:-- |
| Type:Valid Description: | AUTOSAR communication shall support geo-networking, transport protocols and facility protocols for Vehicle-2-X applications as defined by ETSI |
| Rationale: | Geo-networking (GN) and the basic transport protocol (BTP) are essential components of a V2X stack. The facilities (FAC) implement the functionality for reception and transmission of standardized V2X messages. V2X facilities also build the interface for vehicle specific applications. For the European market they especially support decoding, encoding and management of cooperative awareness messages. All protocols are accompanied by standardized mechanisms to secure privacy and maintain availability of the service in highly congested areas |
| Use Case: | Examples e.g. enhance traffic flow by provision of infrastructure messages (traffic lights ahead, ...) to software components, implementation of standardized sending applications |
| Applies to: | CP, AP |
| Dependencies: | -- |
| Supporting Material: | EN 302 636, EN 302 636, ETSI TS 102 636-3 |