autosar os alarm_autosar开发工具有哪些

作者：Stephen Du

免责声明： 本文为个人学习笔记及总结，仅代表个人观点，尽可能保证内容准确性。复制/转发请注明来源/作者。

欢迎添加微信交流学习。

AUTOSAR Overview of different version

1. AUTOSAR History Overview

2. Summary of Changes

2.1 Main Function – V 1.0

• Proof of Concept

2.2 Summary of Changes – V 2.0

• Specifications of components(BSW and RTE)

2.3 Summary of Changes – V 2.1

• Includes specifications on development methodology and templates
• First descriptions for application interfaces(body and interior electronics)

2.4 Summary of Changes – V 3.0

• 20 compositions from the body, powertrain and chassis domain
• Specifications of standardized application interfaces (powertrain, chassis domain)
• Harmonized the concept for wakeup of ECUS and startup of networks
• State managers for the bus systems CAN, LIN, and FlexRay added

2.5 Summary of Changes – V 3.1

• OBDII (new revisions of the DCM, DEM, FIM specifications,…)

2.6 Summary of Changes – V 3.2

• Partial Networking

• Robustness Features

• Improvement of error handing (e.g. production vs. development errors)

• Back-porting of AUTOSAR 4.0 features into AUTOSAR 3.2

  • Safety Concept (E2E communication protection)
  • Extended CDD Concept
  • BSW Mode Manager
  • FlexRay ISO TP

2.7 Summary of Changes – V 4.0

• Functional Safety

  • Memory Partitioning Concept
  • Time Determinism Concept
  • Program Flow Monitoring Concept
  • SW-C E2E Comm protection Concept
  • BSWM Defensive Behavior Concept
  • Dual Microcontroller Concept
  • E-Gas Monitoring Applicability Concept

• Architectural Improvements

  • Error Handling Concept
  • Multi Core Architectures Concept
  • Bootloader Interaction Concept
  • Build System Enhancement Concept
  • Memory Related Concept
  • Support of Windowed Watchdog Concept
  • Enabling CDDs in the BSW Architecture Concept

• RTE enhancement

  • Triggered Event Concept
  • Integrity and Scaling at Ports Concept
  • RTE API Enhancement Concept

• Evolution of COM

  • LIN 2.1 Std Concept
  • Flex Ray Spec 3.0 Concept
  • XCP for AUTOSAR Concept
  • TCP/IP CommStack Extensions Concept
  • Support of Large Data Types Concept

• Functional enhancements

  • VMM AMM Concept
  • Support of SAE J1939 Protocol Features Concept
  • NM Coordination Concept
  • AUTOSAR Scheduler Harmonization Concept
  • Functional Diagnostic of SWC Concept
  • Communication Stack Concept

• Debugging

  • Debugging Concept
  • Log and Trace Concept

• Enhancement of M&T

  • Variant Handling Concept
  • Methodology Refinement Concept
  • Timing Model Concept
  • ECUC Parameter Definition Harmonization Concept
  • M2 Support Concept for Documentation on M1 Level
  • M2 Support Concept for Definition of Calibration Data Sets on M1 level
  • Calculation Formula Language Concept
  • Specification Improvement for the ECU Extract Concept
  • Meta Model Cleanup Concept

2.8 Summary of Changes – V 4.1

• Architecture Enhancements (BSW & RTE)

  • Completion of CDD Concept
  • Updated OSApplication Termination Functionality
  • TimeService And TimerConformanceClasses
  • Enhanced BSW allocation in partitioned systems
  • Define resource locking behavior
  • Enhanced compatibility of Ports
  • Partial Networking on Ethernet
  • Secure Key Storage Support in Crypto Service Manager (CSM)
  • Output compare unit driver
  • Socket-Interface for applications to communicate via TCP/IP
  • Support for Heavy Duty Vehicles and J1939
  • BSW & RTE Configuration Profiles
  • Pretended Networking
  • Combined require and provide semantic of Ports
  • Provide activating RTE-Event
  • Rapid prototyping implementation
  • ECU Degradation

• Methodology & Templates

  • Define Implicit Communication Behavior Description
  • Harmonize Definition of ECUC Parameters
  • Refined Scheduling of Runnables
  • Continued Harmonization with FIBEX (FIBEX4MOST)
  • AUTOSAR Timing Concept
  • Abstract System Description
  • Roles And Rights
  • Processor Manifest
  • AUTOSAR Feature Model Exchange Format

• Application Interfaces

  • Life Cycles
  • Variant Handling for Application Interfaces

2.9 Summary of Changes – V 4.2

• CAN FD
  Support of CAN FD, allowing switching to a faster bit rate after the arbitration, higher data rates than 1 Mbit/s and payloads longer than 8 bytes per frame.
• Decentralized Configuration
  This concept allows the configuration of the “Diagnostic Extract” – the demand of diagnostic services and fault memory content – in the System Description.
• Global Time Synchronization
  Mechanisms to distribute one or more master time bases across various buses and bus systems.
• Integration of Non-AUTOSAR Systems Safety Extensions
  Extension of AUTOSAR description means, process, and technology in such a way that other — non-AUTOSAR — software systems can be integrated into an AUTOSAR system during its development.

2.10 Summary of Changes – V 4.3

• Hardware Test Management on Startup and Shutdown
  The concept introduces interfaces that allow the monitoring of the startup and shutdown hardware tests on a running AUTOSAR system.
• Crypto Interface
  The concept completes the AUTOSAR crypto stack by adding Crypto Interface and Crypto Driver. These new modules allow the integration of heterogeneous hardware and software solutions.
  Together with the concept, the Crypto Service Manager has been reworked to provide a unique interface, meeting all requirements of today’s automotive security.
• V2X Support
  The concept V2X Support adds support of Vehicle2X communication mechanisms to the AUTOSAR standard, especially the support of wireless ITS-G5 message handling and support of V2X applications distributed over multiple ECUs in a vehicle network.
• Profile for Data Exchange Points
  The concept “Profile for Data Exchange Points” aims for improving the inter-operability between AUTOSAR tools by providing means for describing which data is expected for a given data exchange point.
• SOME/IP Transport Protocol (Segmenter)
  The concept introduces a SOME/IP segmenter module to enable handling of SOME/IP messages bigger than 127kByte.

2.11 Summary of Changes – V 4.4

• ASAMUnits

The concept defines a standardized collection of BluePrint-definitions of Physical Units and related to this a collection of Physical Dimension BluePrint-definitions.
All definitions are synchronized between ASAM and AUTOSAR and should be used whenever interfaces between SW and physical world are described.

• AUTOSARRunTimeInterface

The concept “AUTOSARRunTimeInterface” is released as draft and will be validated in 2019.
The concept “ARTI” defines an interface between build tools and debugging/tracing tools to the AUTOSAR standard. It defines standardized hooks that AUTOSAR components shall contain and also defines a model to export information about the internal representation of the components to ease debugging and tracing.

• RTEImplementationPlugIns

The concept “RTEImplementationPlugIns” is released as draft and will be validated in 2019.
The concept supports the modular implementation of the RTE with a standard RTE Generator and specialized RTE Plug-Ins.

• LINSlaveSupport

The concept introduces the modeling and implementation of LIN slave nodes into the AUTOSAR LIN communication stack.

• Formal Model Query and Blueprint Derivation Mechanisms

The concept “Formal Model Query and Blueprint Derivation Mechanisms” is released as draft and will be validated in 2019.
The concept completes the extension of AUTOSAR Classic (CP) and Adaptive platforms (AP) with the AUTOSAR Model Query Language (ARMQL). This new language enables a highly efficient collaboration of AUTOSAR users due to resolving variation points in CP and AP by the same mechanism. It is published in textual form, not bound to a specific tool and significant better understandable as the existing Formula Language.

• BusMirroring

The concept enables an external tester to listen to the traffic on and check the status of internal communication busses which are not directly accessible to this tester. It introduces a new Mirroring component that can forward LIN and CAN traffic to CAN and can create serialized datagrams that reflect communication on LIN, CAN, and FlexRay busses for transmission over FlexRay or Ethernet. To avoid flooding of intermediate networks, the traffic on monitored buses can be filtered.

• SecurityExtensions

The concept adds important security controls to the AUTOSAR framework which support the efficient implementation of secure automotive systems.
The extensions include secure logging, vehicle key and certificate management, authentic time and diagnostic policy management.

• MCALMulticoreDistribution

The concept “MCALMulticoreDistribution” is released as draft and will be validated in 2019.
This concept describes, how different multicore capabilities of MCAL drivers can be realized and declared by those driver modules. These capabilities enable advanced multicore use cases for application and base software and improve reusability due to the well-known functional scope of the drivers.

• Logical Execution Time

The concept extends the TIMEX with capabilities to specify that data exchange via sender-receiver communication is performed at predefined points in time.
The essential properties of LET intervals (start, end, duration) are introduced as well as their timing behavior (trigger, offset between LET intervals).

• TransportLayerSecurity

The concept “TransportLayerSecurity” is released as draft and will be validated in 2019.
The concept provides the ability to establish a secure ad-hoc session between two Ethernet nodes based on the well-known Transport Layer Security (TLS) standard. This allows to establish an authentic and confidential communication between two ECUs or between an ECU and an external entities.

3. List of Basic Software Module（Module Counts: 103）

x¹ : Since V4.0, this module is integrated within the RTE.

x: Support in this version

-: Not support in this version

今天的文章autosar os alarm_autosar开发工具有哪些分享到此就结束了，感谢您的阅读。