fbpx
Wikipedia

AUTOSAR

AUTomotive Open System ARchitecture (AUTOSAR) is a development partnership of automotive interested parties founded in 2003. It pursues the objective to create and establish an open and standardized software architecture for automotive electronic control units (ECUs). Goals include the scalability to different vehicle and platform variants, transferability of software, the consideration of availability and safety requirements, a collaboration between various partners, sustainable use of natural resources, and maintainability during the product lifecycle.[1][2][3]

AUTOSAR
TypeDevelopment Partnership
IndustryAutomotive, E/E, Software, Semiconductor
Founded2003
HeadquartersMunich, Germany (Administration)
Key people
  • Rinat Asmus (Chairperson, 2022)
  • Michael Niklas-Höret (Deputy Chairperson, 2022)
Members327 Companies (03/2022)
Websiteautosar.org

History

AUTOSAR was formed in July 2003 by Bavarian Motor Works (BMW), Robert Bosch GmbH, Continental AG, Daimler AG (formerly Daimler-Benz, then DaimlerChrysler), Siemens VDO, and Volkswagen to promote an open industry standard for automotive electrical-electronic (E/E) architecture. In November 2003, Ford Motor Company joined as a core partner, and in December, Groupe PSA (formerly PSA Peugeot Citroën) and Toyota Motor Corporation joined. The following November, General Motors also became a core partner. After Siemens VDO was acquired by Continental in February 2008, it ceased being an independent core partner.

Since 2003, AUTOSAR provided four major releases of the automotive software architecture for its classic platform and one release of acceptance tests. The work can be divided into three phases:

  • Phase I (2004–2006): Basic development of the standard (releases 1.0, 2.0, 2.1)[4]
  • Phase II (2007–2009): Extension of the standard in architecture and methodology (releases 3.0, 3.1, 4.0)[5]
  • Phase III (2010–2013): Maintenance and selected improvements (releases 3.2, 4.1, 4.2)[6]

In 2013, AUTOSAR entered a continuous working mode for its classic Platform to maintain the standard and provide selected improvements, including releases R4.2, and 1.0 of acceptance tests.

In 2016, work on the Adaptive Platform began. A first release (17-03) was published in early 2017, followed by release 17-10 in October 2017[7] and release 18-03 in March 2018.[8] With release 18-10 in October 2018, major development activities were published.[9]

In December 2020, AUTOSAR R20-11 was virtually released.[10]

Concept and goals

AUTOSAR provides specifications of basic software modules, defines application interfaces and builds a common development methodology based on standardized exchange format. Basic software modules made available by the AUTOSAR layered software architecture can be used in vehicles of different manufacturers and electronic components of different suppliers, thereby reducing expenditures for research and development.[6]

Based on this principle, AUTOSAR aims to prepare for upcoming technologies.[11][1]

Software architecture

AUTOSAR uses a three-layer architecture:[12]

  • Basic Software: standardized software modules (mostly) with no explicit automotive job, but offers services needed to run the functional part of the upper software layer.[13]
  • Runtime environment (RTE): middleware which abstracts from the network topology for the inter- and intra-ECU information exchange between the application software components and between the Basic Software and the applications.[14]
  • Application Layer: application software components that interact with the runtime environment.[15]

Methodology

  • System Configuration Description includes all system information and the information agreed between different ECUs (e.g. definition of bus signals).
  • ECU extract: contains the information from the System Configuration Description needed for a specific ECU (e.g. those signals where a specific ECU has access to).
  • ECU Configuration Description: contains all basic software configuration information that is local to a specific ECU. Use this information to build the executable software, the code of the basic software modules and the code of the software components out of it.[16][17]

Classic Platform

The AUTOSAR classic platform is the standard for embedded real-time ECUs based on OSEK. Its main deliverable is specifications.

The architecture distinguishes between three software layers that run on a microcontroller: application, runtime environment (RTE) and basic software (BSW). The application software layer is mostly hardware independent. Communication between software components and access to BSW happens via RTE, which represents the full interface for applications.

The BSW is divided in three major layers and complex drivers:

  • Services
  • Electronic control unit (ECU) abstraction
  • Microcontroller abstraction

Services are divided further, into functional groups representing the infrastructure for system, memory and communication services.

One essential concept of the Classic Platform is the Virtual Functional Bus (VFB). This virtual bus is an abstract set of RTEs that are not yet deployed to specific ECUs and decouples the applications from the infrastructure. It communicates via dedicated ports, which means that the communication interfaces of the application software must be mapped to these ports. The VFB handles communication within the individual ECU and between ECUs. From an application point of view, no detailed knowledge of lower-level technologies or dependencies is required. This supports hardware-independent development and usage of application software.

The Classic Platform also enables the integration of non-AUTOSAR systems such as GENIVI, now renamed COVESA, by using the Franca Interface Definition Language (Franca IDL).[18]

Adaptive platform

New use-cases required the development of the adaptive platform. One example is automated driving, in the context of which the driver temporarily and/or partially transfers responsibility for driving to the vehicle. This can require communication with traffic infrastructure (e.g. traffic signs and -lights), cloud servers (e.g. to access the latest traffic information or map data), or the use of microprocessors and high-performance computing hardware for parallel processing, e.g., graphics processing units (GPUs).

Further, Car-2-X applications require interaction to vehicles and off-board systems. That means that the system has to provide secure on-board communication, support of cross-domain computing platforms, smartphone integration, integration of non-AUTOSAR systems, and so on. Also, cloud-based services will require dedicated means for security, such as secure cloud interaction and emergency vehicle preemption. They will enable remote and distributed services, such as remote diagnostics, over the air (OTA) update, repair, and exchange handling.

To support dynamic deployment of customer applications and to provide an environment for applications that require high-end computing power AUTOSAR is currently standardizing the AUTOSAR Adaptive Platform. Its core is an operating system based on the POSIX standard. The operating system can be used from the application via a subset of the POSIX according to IEEE1003.13 (namely PSE51). One of the key features of the Adaptive Platform is service-oriented communication since the Platform is based on the Service - Oriented Architecture.[19]

Adaptive AUTOSAR is developed and written using C++ which is an object-oriented programming language. The communication protocol used for the in-vehicle networking is SOME/IP, based on Ethernet. Two types of interfaces are available: services and application programming interfaces (APIs). The platform consists of functional clusters which are grouped in services and the AUTOSAR adaptive platform foundation.

Functional clusters:

  • Assemble functions of the adaptive platform
  • Define clustering of requirements specification
  • Describe behavior of software platform from application and network perspective
  • Do not constrain the final SW design of the architecture implementing the Adaptive Platform.

Functional clusters in AUTOSAR Adaptive Platform have to have at least one instance per (virtual) machine while services may be distributed in the in-car network.

Adaptive platform services include:

  • Update and Configuration management
  • State Management
  • Network Management
  • Diagnostics

The adaptive platform contains both specification and code. In comparison to the Classic Platform, AUTOSAR develops an implementation to shorten the validation cycle and illustrate the underlying concepts. This implementation is available to all AUTOSAR partners.[20][21][22][19][23]

Foundation

The purpose of the foundation standard is to enforce interoperability between the AUTOSAR platforms. The foundation contains common requirements and technical specifications (for example protocols) shared between the AUTOSAR platforms, and the common methodology.[24][25]

Acceptance tests

In 2014, acceptance tests were introduced to minimize test efforts and costs. Acceptance test Specifications are system test specifications using the specified interfaces of the respective Platform. Also, they are considering the specified behavior on the bus. They can be seen as a black box test case for a given platform function. The specification of standard acceptance tests contributes to these objectives.[26][27]

Standardized application interfaces

Standardization of functional interfaces across manufacturers and suppliers and standardization of the interfaces between the different software layers is seen as a basis for achieving the technical goals of AUTOSAR.[28][29] Only by standardizing concrete interface contents in their physical and temporal representation allows achieving the needed integration compatibility.

Organization

AUTOSAR defined six different levels of membership. The contribution of partners varies depending on the type of partnership:[30][31]

  • Core Partner
  • Strategic Partner
  • Premium Partner
  • Associate Partner
  • Development Partner
  • Attendee

Core Partners include the founding partners BMW, Bosch, Continental, Daimler AG, Ford, General Motors, PSA Peugeot Citroën, Toyota, and Volkswagen.[32] These companies are responsible for organization, administration and control of the AUTOSAR development partnership.[30] Within this core, the Executive Board defines the overall strategy and roadmap.[33] The Steering Committee manages day-to-day non-technical operations and admission of partners, public relations and contractual issues.[34] The Chairman and Deputy of Chairman, appointed for one year, represent the Steering Committee for that purpose.[35] The AUTOSAR Spokesperson takes over the communication with the outside world.[36][37]

Strategic partners are appointed for a period of two years from the circle of Premium Partners and support the project leader team in the various technical, organizational and everyday processes. They also give new strategic inputs to the project leader round.

Premium and Development members contribute to work packages coordinated and monitored by the Project Leader Team established by the Core Partners.[30][38] Associate partners are making use of the standard documents AUTOSAR has already released.[39] Attendees are currently participating with Academic collaboration and non-commercial projects.[40]

Vendors

Selection of vendors, including RTOS, BSW, design tools, compiler, etc.[41]

AUTOSAR-related software vendors and partners

Vendors which provide related tools and software, e.g. for testing, diagnostics, development, etc.

Competitors or related consortia

See also

References

  1. ^ a b "Elektrobit Automotive: AUTOSAR". Retrieved 11 December 2015.
  2. ^ "AUTOSAR official website". AUTOSAR. 5 June 2018.
  3. ^ Scheid, Oliver (2015). AUTOSAR Compendium - Part 1: Application & RTE. Bruchsal: CreateSpace Independent Publishing Platform.
  4. ^ Fennel, H.; Helmut, S.; Bielefeld, J.; et al. (2006). "Achievements and exploitation of the AUTOSAR development partnership". Convergence 2006: 10.
  5. ^ "AUTOSAR — The Worldwide Automotive Standard for E/E Systems". ATZextra Worldwide. 18 (9): 5–12. October 2013. doi:10.1007/s40111-013-0003-5. ISSN 2195-1470.
  6. ^ a b (PDF). Archived from the original (PDF) on 19 December 2015. Retrieved 11 December 2015.
  7. ^ "Adaptive Platform_Release_17_10_EN" (PDF). AUTOSAR. 20 December 2017.
  8. ^ "AUTOSAR_Release_18_03_EN" (PDF). AUTOSAR. 23 April 2018.
  9. ^ "History". www.autosar.org. Retrieved 14 May 2018.
  10. ^ cooperation, AUTOSAR development. "AUTOSAR R20-11 Release Event". www.autosar.org. Retrieved 9 December 2020.
  11. ^ . Archived from the original on 19 December 2015. Retrieved 11 December 2015.
  12. ^ "AUTOSAR: The worldwide automotive standard for e/e systems", ATZextra, Springer Fachmedien Wiesbaden, 18: 9–10, October 2013, ISSN 2195-1454
  13. ^ . Archived from the original on 19 December 2015. Retrieved 11 December 2015.
  14. ^ . Archived from the original on 19 December 2015. Retrieved 11 December 2015.
  15. ^ . Archived from the original on 19 December 2015. Retrieved 11 December 2015.
  16. ^ . Archived from the original on 19 December 2015. Retrieved 11 December 2015.
  17. ^ Chaaban, Khaled; Leserf, Patrick; Saudrais, Sebastien (September 2009). "Steer-By-Wire system development using AUTOSAR methodology". 2009 IEEE Conference on Emerging Technologies & Factory Automation. Mallorca: IEEE: 1–8. doi:10.1109/ETFA.2009.5347123. ISBN 978-1-4244-2727-7. S2CID 16258656.
  18. ^ "Classic Platform". www.autosar.org. Retrieved 2 December 2019.
  19. ^ a b Furst, Simon; Bechter, Markus (June 2016). "AUTOSAR for Connected and Autonomous Vehicles: The AUTOSAR Adaptive Platform". 2016 46th Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshop (DSN-W). Toulouse, France: IEEE: 215–217. doi:10.1109/DSN-W.2016.24. ISBN 978-1-5090-3688-2. S2CID 1133757.
  20. ^ "Adaptive Platform". www.autosar.org. Retrieved 14 May 2018.
  21. ^ "AUTOSAR for Intelligent Vehicles" (PDF). AUTOSAR. 29 November 2017.
  22. ^ "AUTOSAR proofs to be THE automotive software platform for intelligent mobility" (PDF). AUTOSAR. 18 October 2017.
  23. ^ Reichart, Günter; Asmus, Rinat (2021). Bertram, Torsten (ed.). "Progress on the AUTOSAR Adaptive Platform for Intelligent Vehicles". Automatisiertes Fahren 2020. Proceedings (in German). Wiesbaden: Springer Fachmedien: 67–75. doi:10.1007/978-3-658-34752-9_6. ISBN 978-3-658-34752-9. S2CID 240964305.
  24. ^ "Foundation". www.autosar.org. Retrieved 14 May 2018.
  25. ^ Stepanovic, Mia; Bjelica, Milan; Kastelan, Ivan; Velikic, Gordana (January 2020). "Scalable approach to extending automotive software using AUTOSAR adaptive stack". 2020 IEEE International Conference on Consumer Electronics (ICCE). Las Vegas, NV, USA: IEEE: 1–2. doi:10.1109/ICCE46568.2020.9212328. ISBN 978-1-7281-5186-1. S2CID 222221057.
  26. ^ "Acceptance Test". Retrieved 14 May 2018.
  27. ^ Rüping, Thomas; Fürst, Simon; Bechter, Markus (1 September 2015). "Zukunft von Autosar Weiter- und Neuentwicklung". ATZelektronik (in German). 10 (7): 24–29. doi:10.1007/s35658-015-0571-4. ISSN 2192-8878.
  28. ^ . Archived from the original on 19 December 2015. Retrieved 11 December 2015.
  29. ^ "Application Interface". Retrieved 14 May 2018.
  30. ^ a b c (PDF). Archived from the original (PDF) on 19 December 2015. Retrieved 11 December 2015.
  31. ^ "Current Partners". www.autosar.org. Retrieved 14 May 2018.
  32. ^ "Core Partners". www.autosar.org. Retrieved 14 May 2018.
  33. ^ . Archived from the original on 19 December 2015. Retrieved 11 December 2015.
  34. ^ . Archived from the original on 23 September 2015. Retrieved 11 December 2015.
  35. ^ "Autopresse: Autonews". Retrieved 11 December 2015.
  36. ^ . Archived from the original on 19 December 2015. Retrieved 11 December 2015.
  37. ^ "AUTOSAR Chairman handover Press Release" (PDF). AUTOSAR. 21 November 2017.
  38. ^ . Archived from the original on 19 December 2015. Retrieved 11 December 2015.
  39. ^ "Associate Partners". www.autosar.org. Retrieved 14 May 2018.
  40. ^ "Attendees". www.autosar.org. Retrieved 14 May 2018.
  41. ^ cooperation, AUTOSAR development. "Vendor IDs". www.autosar.org. Retrieved 25 February 2021.
  42. ^ "Generating ARXML and C code". www.ibm.com. 17 October 2017. Retrieved 10 April 2021.

Further reading

  • Scheid, Oliver (2015). AUTOSAR Compendium: Part 1: Application & RTE. p. 406. ISBN 978-1-50275-152-2.
  • Kindel, Olaf; Friedrich, Mario (2009). Software Development with AUTOSAR (Softwareentwicklung mit AUTOSAR). dpunkt.verlag. p. 300. ISBN 978-3-89864-563-8.
  • Staron, Miroslaw (2021). Automotive Software Architectures - An Introduction. Springer. ISBN 978-3-030-65938-7.

External links

  • Official website
  • AUTOSAR user groups (COMASSO, etc.)

autosar, automotive, open, system, architecture, development, partnership, automotive, interested, parties, founded, 2003, pursues, objective, create, establish, open, standardized, software, architecture, automotive, electronic, control, units, ecus, goals, i. AUTomotive Open System ARchitecture AUTOSAR is a development partnership of automotive interested parties founded in 2003 It pursues the objective to create and establish an open and standardized software architecture for automotive electronic control units ECUs Goals include the scalability to different vehicle and platform variants transferability of software the consideration of availability and safety requirements a collaboration between various partners sustainable use of natural resources and maintainability during the product lifecycle 1 2 3 AUTOSARTypeDevelopment PartnershipIndustryAutomotive E E Software SemiconductorFounded2003HeadquartersMunich Germany Administration Key peopleRinat Asmus Chairperson 2022 Michael Niklas Horet Deputy Chairperson 2022 Members327 Companies 03 2022 Websiteautosar wbr org Contents 1 History 2 Concept and goals 3 Software architecture 3 1 Methodology 3 2 Classic Platform 3 3 Adaptive platform 3 4 Foundation 3 5 Acceptance tests 3 6 Standardized application interfaces 4 Organization 4 1 Vendors 4 2 AUTOSAR related software vendors and partners 4 3 Competitors or related consortia 5 See also 6 References 7 Further reading 8 External linksHistory EditAUTOSAR was formed in July 2003 by Bavarian Motor Works BMW Robert Bosch GmbH Continental AG Daimler AG formerly Daimler Benz then DaimlerChrysler Siemens VDO and Volkswagen to promote an open industry standard for automotive electrical electronic E E architecture In November 2003 Ford Motor Company joined as a core partner and in December Groupe PSA formerly PSA Peugeot Citroen and Toyota Motor Corporation joined The following November General Motors also became a core partner After Siemens VDO was acquired by Continental in February 2008 it ceased being an independent core partner Since 2003 AUTOSAR provided four major releases of the automotive software architecture for its classic platform and one release of acceptance tests The work can be divided into three phases Phase I 2004 2006 Basic development of the standard releases 1 0 2 0 2 1 4 Phase II 2007 2009 Extension of the standard in architecture and methodology releases 3 0 3 1 4 0 5 Phase III 2010 2013 Maintenance and selected improvements releases 3 2 4 1 4 2 6 In 2013 AUTOSAR entered a continuous working mode for its classic Platform to maintain the standard and provide selected improvements including releases R4 2 and 1 0 of acceptance tests In 2016 work on the Adaptive Platform began A first release 17 03 was published in early 2017 followed by release 17 10 in October 2017 7 and release 18 03 in March 2018 8 With release 18 10 in October 2018 major development activities were published 9 In December 2020 AUTOSAR R20 11 was virtually released 10 Concept and goals EditAUTOSAR provides specifications of basic software modules defines application interfaces and builds a common development methodology based on standardized exchange format Basic software modules made available by the AUTOSAR layered software architecture can be used in vehicles of different manufacturers and electronic components of different suppliers thereby reducing expenditures for research and development 6 Based on this principle AUTOSAR aims to prepare for upcoming technologies 11 1 Software architecture EditAUTOSAR uses a three layer architecture 12 Basic Software standardized software modules mostly with no explicit automotive job but offers services needed to run the functional part of the upper software layer 13 Runtime environment RTE middleware which abstracts from the network topology for the inter and intra ECU information exchange between the application software components and between the Basic Software and the applications 14 Application Layer application software components that interact with the runtime environment 15 Methodology Edit System Configuration Description includes all system information and the information agreed between different ECUs e g definition of bus signals ECU extract contains the information from the System Configuration Description needed for a specific ECU e g those signals where a specific ECU has access to ECU Configuration Description contains all basic software configuration information that is local to a specific ECU Use this information to build the executable software the code of the basic software modules and the code of the software components out of it 16 17 Classic Platform Edit The AUTOSAR classic platform is the standard for embedded real time ECUs based on OSEK Its main deliverable is specifications The architecture distinguishes between three software layers that run on a microcontroller application runtime environment RTE and basic software BSW The application software layer is mostly hardware independent Communication between software components and access to BSW happens via RTE which represents the full interface for applications The BSW is divided in three major layers and complex drivers Services Electronic control unit ECU abstraction Microcontroller abstractionServices are divided further into functional groups representing the infrastructure for system memory and communication services One essential concept of the Classic Platform is the Virtual Functional Bus VFB This virtual bus is an abstract set of RTEs that are not yet deployed to specific ECUs and decouples the applications from the infrastructure It communicates via dedicated ports which means that the communication interfaces of the application software must be mapped to these ports The VFB handles communication within the individual ECU and between ECUs From an application point of view no detailed knowledge of lower level technologies or dependencies is required This supports hardware independent development and usage of application software The Classic Platform also enables the integration of non AUTOSAR systems such as GENIVI now renamed COVESA by using the Franca Interface Definition Language Franca IDL 18 Adaptive platform Edit New use cases required the development of the adaptive platform One example is automated driving in the context of which the driver temporarily and or partially transfers responsibility for driving to the vehicle This can require communication with traffic infrastructure e g traffic signs and lights cloud servers e g to access the latest traffic information or map data or the use of microprocessors and high performance computing hardware for parallel processing e g graphics processing units GPUs Further Car 2 X applications require interaction to vehicles and off board systems That means that the system has to provide secure on board communication support of cross domain computing platforms smartphone integration integration of non AUTOSAR systems and so on Also cloud based services will require dedicated means for security such as secure cloud interaction and emergency vehicle preemption They will enable remote and distributed services such as remote diagnostics over the air OTA update repair and exchange handling To support dynamic deployment of customer applications and to provide an environment for applications that require high end computing power AUTOSAR is currently standardizing the AUTOSAR Adaptive Platform Its core is an operating system based on the POSIX standard The operating system can be used from the application via a subset of the POSIX according to IEEE1003 13 namely PSE51 One of the key features of the Adaptive Platform is service oriented communication since the Platform is based on the Service Oriented Architecture 19 Adaptive AUTOSAR is developed and written using C which is an object oriented programming language The communication protocol used for the in vehicle networking is SOME IP based on Ethernet Two types of interfaces are available services and application programming interfaces APIs The platform consists of functional clusters which are grouped in services and the AUTOSAR adaptive platform foundation Functional clusters Assemble functions of the adaptive platform Define clustering of requirements specification Describe behavior of software platform from application and network perspective Do not constrain the final SW design of the architecture implementing the Adaptive Platform Functional clusters in AUTOSAR Adaptive Platform have to have at least one instance per virtual machine while services may be distributed in the in car network Adaptive platform services include Update and Configuration management State Management Network Management DiagnosticsThe adaptive platform contains both specification and code In comparison to the Classic Platform AUTOSAR develops an implementation to shorten the validation cycle and illustrate the underlying concepts This implementation is available to all AUTOSAR partners 20 21 22 19 23 Foundation Edit The purpose of the foundation standard is to enforce interoperability between the AUTOSAR platforms The foundation contains common requirements and technical specifications for example protocols shared between the AUTOSAR platforms and the common methodology 24 25 Acceptance tests Edit In 2014 acceptance tests were introduced to minimize test efforts and costs Acceptance test Specifications are system test specifications using the specified interfaces of the respective Platform Also they are considering the specified behavior on the bus They can be seen as a black box test case for a given platform function The specification of standard acceptance tests contributes to these objectives 26 27 Standardized application interfaces Edit Standardization of functional interfaces across manufacturers and suppliers and standardization of the interfaces between the different software layers is seen as a basis for achieving the technical goals of AUTOSAR 28 29 Only by standardizing concrete interface contents in their physical and temporal representation allows achieving the needed integration compatibility Organization EditAUTOSAR defined six different levels of membership The contribution of partners varies depending on the type of partnership 30 31 Core Partner Strategic Partner Premium Partner Associate Partner Development Partner AttendeeCore Partners include the founding partners BMW Bosch Continental Daimler AG Ford General Motors PSA Peugeot Citroen Toyota and Volkswagen 32 These companies are responsible for organization administration and control of the AUTOSAR development partnership 30 Within this core the Executive Board defines the overall strategy and roadmap 33 The Steering Committee manages day to day non technical operations and admission of partners public relations and contractual issues 34 The Chairman and Deputy of Chairman appointed for one year represent the Steering Committee for that purpose 35 The AUTOSAR Spokesperson takes over the communication with the outside world 36 37 Strategic partners are appointed for a period of two years from the circle of Premium Partners and support the project leader team in the various technical organizational and everyday processes They also give new strategic inputs to the project leader round Premium and Development members contribute to work packages coordinated and monitored by the Project Leader Team established by the Core Partners 30 38 Associate partners are making use of the standard documents AUTOSAR has already released 39 Attendees are currently participating with Academic collaboration and non commercial projects 40 Vendors Edit This list is incomplete you can help by adding missing items February 2021 Selection of vendors including RTOS BSW design tools compiler etc 41 Elektrobit now part of Continental AG embitel ETAS KPIT Technologies Siemens previously Mentor Graphics Vector InformatikAUTOSAR related software vendors and partners Edit Vendors which provide related tools and software e g for testing diagnostics development etc dSPACE GmbH MATLAB by MathWorksCompetitors or related consortia Edit Automotive Grade Linux COMASSO Organization provides an open source AUTOSAR platform GENIVI AllianceSee also EditAutomotive SPICE A software process assessment framework required by or relating to some specifications of AUTOSAR Electronic control unit ECU Embedded system ISO 26262 Functional safety norm required by or relating to some specifications of AUTOSAR List of requirements engineering tools Tools for ARXML MBSE modelling such as IBM s Rhapsody 42 Modeling language MISRA OSEK Software architectureReferences Edit a b Elektrobit Automotive AUTOSAR Retrieved 11 December 2015 AUTOSAR official website AUTOSAR 5 June 2018 Scheid Oliver 2015 AUTOSAR Compendium Part 1 Application amp RTE Bruchsal CreateSpace Independent Publishing Platform Fennel H Helmut S Bielefeld J et al 2006 Achievements and exploitation of the AUTOSAR development partnership Convergence 2006 10 AUTOSAR The Worldwide Automotive Standard for E E Systems ATZextra Worldwide 18 9 5 12 October 2013 doi 10 1007 s40111 013 0003 5 ISSN 2195 1470 a b AUTOSAR Shaping the future of a Global Standard PDF Archived from the original PDF on 19 December 2015 Retrieved 11 December 2015 Adaptive Platform Release 17 10 EN PDF AUTOSAR 20 December 2017 AUTOSAR Release 18 03 EN PDF AUTOSAR 23 April 2018 History www autosar org Retrieved 14 May 2018 cooperation AUTOSAR development AUTOSAR R20 11 Release Event www autosar org Retrieved 9 December 2020 AUTOSAR Motivation amp Goals Archived from the original on 19 December 2015 Retrieved 11 December 2015 AUTOSAR The worldwide automotive standard for e e systems ATZextra Springer Fachmedien Wiesbaden 18 9 10 October 2013 ISSN 2195 1454 AUTOSAR Basic Software Archived from the original on 19 December 2015 Retrieved 11 December 2015 AUTOSAR Runtime Environment Archived from the original on 19 December 2015 Retrieved 11 December 2015 AUTOSAR Software Archived from the original on 19 December 2015 Retrieved 11 December 2015 AUTOSAR Methodology Archived from the original on 19 December 2015 Retrieved 11 December 2015 Chaaban Khaled Leserf Patrick Saudrais Sebastien September 2009 Steer By Wire system development using AUTOSAR methodology 2009 IEEE Conference on Emerging Technologies amp Factory Automation Mallorca IEEE 1 8 doi 10 1109 ETFA 2009 5347123 ISBN 978 1 4244 2727 7 S2CID 16258656 Classic Platform www autosar org Retrieved 2 December 2019 a b Furst Simon Bechter Markus June 2016 AUTOSAR for Connected and Autonomous Vehicles The AUTOSAR Adaptive Platform 2016 46th Annual IEEE IFIP International Conference on Dependable Systems and Networks Workshop DSN W Toulouse France IEEE 215 217 doi 10 1109 DSN W 2016 24 ISBN 978 1 5090 3688 2 S2CID 1133757 Adaptive Platform www autosar org Retrieved 14 May 2018 AUTOSAR for Intelligent Vehicles PDF AUTOSAR 29 November 2017 AUTOSAR proofs to be THE automotive software platform for intelligent mobility PDF AUTOSAR 18 October 2017 Reichart Gunter Asmus Rinat 2021 Bertram Torsten ed Progress on the AUTOSAR Adaptive Platform for Intelligent Vehicles Automatisiertes Fahren 2020 Proceedings in German Wiesbaden Springer Fachmedien 67 75 doi 10 1007 978 3 658 34752 9 6 ISBN 978 3 658 34752 9 S2CID 240964305 Foundation www autosar org Retrieved 14 May 2018 Stepanovic Mia Bjelica Milan Kastelan Ivan Velikic Gordana January 2020 Scalable approach to extending automotive software using AUTOSAR adaptive stack 2020 IEEE International Conference on Consumer Electronics ICCE Las Vegas NV USA IEEE 1 2 doi 10 1109 ICCE46568 2020 9212328 ISBN 978 1 7281 5186 1 S2CID 222221057 Acceptance Test Retrieved 14 May 2018 Ruping Thomas Furst Simon Bechter Markus 1 September 2015 Zukunft von Autosar Weiter und Neuentwicklung ATZelektronik in German 10 7 24 29 doi 10 1007 s35658 015 0571 4 ISSN 2192 8878 AUTOSAR Technical Overview Archived from the original on 19 December 2015 Retrieved 11 December 2015 Application Interface Retrieved 14 May 2018 a b c AUTOSAR Basic Information PDF Archived from the original PDF on 19 December 2015 Retrieved 11 December 2015 Current Partners www autosar org Retrieved 14 May 2018 Core Partners www autosar org Retrieved 14 May 2018 AUTOSAR Executive Board Archived from the original on 19 December 2015 Retrieved 11 December 2015 AUTOSAR Steering Committee Archived from the original on 23 September 2015 Retrieved 11 December 2015 Autopresse Autonews Retrieved 11 December 2015 AUTOSAR Spokesperson Archived from the original on 19 December 2015 Retrieved 11 December 2015 AUTOSAR Chairman handover Press Release PDF AUTOSAR 21 November 2017 AUTOSAR Project Leader Team Archived from the original on 19 December 2015 Retrieved 11 December 2015 Associate Partners www autosar org Retrieved 14 May 2018 Attendees www autosar org Retrieved 14 May 2018 cooperation AUTOSAR development Vendor IDs www autosar org Retrieved 25 February 2021 Generating ARXML and C code www ibm com 17 October 2017 Retrieved 10 April 2021 Further reading EditScheid Oliver 2015 AUTOSAR Compendium Part 1 Application amp RTE p 406 ISBN 978 1 50275 152 2 Kindel Olaf Friedrich Mario 2009 Software Development with AUTOSAR Softwareentwicklung mit AUTOSAR dpunkt verlag p 300 ISBN 978 3 89864 563 8 Staron Miroslaw 2021 Automotive Software Architectures An Introduction Springer ISBN 978 3 030 65938 7 External links EditOfficial website AUTOSAR user groups COMASSO etc Retrieved from https en wikipedia org w index php title AUTOSAR amp oldid 1124344203, wikipedia, wiki, book, books, library,

article

, read, download, free, free download, mp3, video, mp4, 3gp, jpg, jpeg, gif, png, picture, music, song, movie, book, game, games.