Today - How complex is an Automotive Software.
https://www.oemoffhighway.com/engineering-manufacturing/software/press-release/21133023/dspace-latest-dspace-targetlink-update-supports-adaptive-autosar#&gid=1&pid=1

Today - How complex is an Automotive Software.

A good example of this kind of car is Tesla, which is known for innovations driven by software.

The software intensive systems in modern cars provide plenty of new opportunities, but they also require more careful design, implementation, verification and validation before they can be released to users.

Year by Year the more control over the complex interactions and prioritizations and therefore led to more advanced software architectures.

In 1975 - Electronic fuel injection, ABS.

1985 - from 1975 + Gearbox control, traction control, dashboard telemetry, CAN.

1995 - from 1985 + ESP, Body control unit, Flexray.

2005 - from 1995 + Electric/Hybrid powertrains, cruise control, emergency braking, ADAS, Autosar.

2015 - from 2005 + Mobility services, autonomous driving, brake and steer by wire, infotainment features, cloud technologies, online and mobile apps, remote diagnosis and control, emergency call processing (SOS).

In today’s cars the size of the software grows to over 100 million lines of code.

Automotive software development is based on a V-model for entire vehicle development and follows international standard ISO/IEC 26262, AUTOSAR and many other to ensure standardization and safety.

1. Software Architectures

? Functional view—describing the architecture of the functions of the vehicle and the dependency between them

? Physical view—describing the physical nodes (ECUs) and their connections

? Logical view—describing the software components and their organization, and

? Deployment view—describing the deployment of software components onto the ECUs

No alt text provided for this image

Your can refer to above link to learn more about the development process.

2. Automotive Software Engineering

? Textual requirements—specifications which are done in form of free text or tables

? Use case requirements—specifications which are based on UML Use cases and the corresponding sequence diagrams

? Model-based requirements—specifications which are done in form of models that should be implemented by suppliers

This verification and validation, done in form of testing

? Unit testing—verification of the functionality of individual software modules

? Component testing—verification of groups of software modules—components

? System testing—verification of the complete system (both of its complete functionality and partial functionality during the course of the development), and

? Functional testing—validation of the end user functions against their specifications

3. AUTOSAR Reference Architecture

No alt text provided for this image

Developed as follows

OEM: responsible for the logical and physical system design.

? Tier1: responsible for the physical ECU design and implementation of the software components allocated to this ECU.

? Tier2: responsible for the implementation of ECU basic software.

? Tier3: responsible for supplying ECU hardware, hardware drivers and corresponding compilers for building the ECU software.

4. Detailed Design of Automotive Software

? Simulink modelling—probably the most widely used method for detailed design of algorithms in the automotive software, usually used in such domains as Powertrain and Active Safety or Chassis development.

? SysML—a UML based method for specifying the software focused on the concepts of the programming languages.

? EAST-ADL—another UML based method for designing the automotive software, combining the problem domain concepts with the programming/system level concepts.

? GENIVI—a standard for programming infotainment systems, which is currently gaining increasingly more popularity in the market.

MATLAB/Simulink - Model based development and testing

The functional requirement is modeled mathematically using Simulink blocks available in the library.

No alt text provided for this image

5. Evaluation of Automotive Software Architectures

The focus on presenting methods based on qualitative evaluations—we focus on Architecture Trade-Off Analysis Method (ATAM). This provide a number of typical scenarios for evaluating safety critical systems.

Under evaluation, validation, calibration and testing these organizations have developed enormous test systems please have a look.

1.National instruments

2.Vector

3.Dspace

6. Metrics for Software Designs and Architectures

International standard ISO/IEC 15939 for software measurement processes

Set of metrics for the detailed designs of the automotive software.

7. Functional Safety of Automotive Software

The major standard in the automotive software today—ISO/IEC 26262 (functional safety).


Thanks for reading, I believe you have learned something new today.

Please share if possible.


References

Google - of course you would expect that.

The article is a mini version of the book mentioned below and added information, Thanking Mr. Miroslaw Staron for his hardwork.

for detailed information refer

No alt text provided for this image




要查看或添加评论,请登录

社区洞察

其他会员也浏览了