Upload
others
View
7
Download
1
Embed Size (px)
Citation preview
FUNCTIONAL SAFETY
Networking
Risk Assessment
Validation
MigrationMBD
MCAL
OSEKhardware
Migration Validation
OSEK Management
ASIL A, B, C,D
Bootloader Production Ready
Tool qualification MBD HardwareASAMValidationASAM TrainingVCI MBD ASAM Optimization
Mode Training
DoIP
BSW stack ConfigurationOSEK R 3.x
ASIL Decomposition
ISO26262 HIS-MISRAHardware
BSW stackMCD3API
Customizable
HardwareBootloader
ASIL Decomposition
ASAM VCI
ISO 26262OSEK
MBDASAM
OSEK
Complex Drivers COM
CAE
ASAM ARTOP Training ECU eNOS
RTE generation CAN
ASAM HIS-MISRACOM
R4.xHIS-MISRA
ODX AUTOSAR
ISO 26262 ASAM ISO 14229OSEK
MANAGEMENT
DIAGNOSTICS
MBD
Production
Partial
ISO 14229
Optimization
ISO 15765 MBD
Optimization
DiagnosticsBoard Support
ModeManagement Complex
DriversMBDPartial Networking
Tool
ManagementECU
MCD3 APINetwork ManagementConsultingMCD3 APIGatewayFUNCTIONAL SAFETY
CT-Spec
MigrationTool chain Mode Management Training ISO 26262 NETWORKValidation
Gateway
Efficient
PC ToolsTraining
BSW stackRemote Diagnostic
Networking
MCD3API
FUNCTIONALSAFETY
DevelopmentError handling ASAM
Production Ready MCAL ISO 15765Network Management Validation
CT-Spec
Customizable
R4.x ODXHIS-MISRA
Gateway
ISO 14229LIN
COM
ARTOP ODX
LIN CAN
VCI
ODX
Partial
LINScalablility
R4.xPartial Networking
Migration DoIP
ECU Risk Assessment Optimization
CAN
ECUR3.xMCD3 API
ECU
network
AUTOSAR
Specifications
hardware
FrugalEngineering
Microlayer
Adaptation
Legacy to MBD
Testingporting ECU
CT SpecsECU
TestingdriversToolchainporting
Microlayerdrivers
R 4.x
Microlayer BSW Stack AUTOSAR
ValidationECU
R 4.x
Scalablility
Mode Management
MCD3API
LIN
Portability ConfigurationASILDecomposition
porting
CT-Spec Production Ready
MBDValidation OSEK Scalability
Tool Qualification CANTraining
Gateway ISO 14229CAN Bootloader
ISO15765
ODX
ISO 15765 Power Window
FUNCTIONAL SAFETY
Testing CoE
RTE generation Error handling ODX
TestingCoE
ARTOP DIAGNOSTICS
Powerseat
Consulting
FUNCTIONAL SAFETY
AUTOSARCT-Spec
Bootloader
Migration OTX Risk Assessment
Gateway HazardAnalysis
OTX ODX Complex DriversCustomizable HIS-MISRA
Network ManagementValidation
Training Gateway
ECU
Testing
eNOS
eNOS
CT Specs
In-vehicle networkValidation
AUTOSARdrivers
ECUSpecifications
R 4.xeNOS
Standardization
MigrationR 3.x ARTOPeNOSPartner Testing MCAL
Validation Tool chain GatewayR 3.x
Testing CoE
Standardization VCI Migration
Mode ODX
Partial OSEK
ASAM CT-Spec Network Hazard Analysis
MBD Management
Validation Scalablility
AUTOSAR Tool chain Training Hardware ManagementMBD
DoIP ASILA, B, C, DASAM MBD
MBD Tool qualification Network
NetworkingMCD3 APITestingPDU RouterASAMProduction Ready MBD
MBD
Validation VCI LIN
ECU
Gateway VCI DoIPValidationConsulting Consulting
ComplexPackage Drivers
SCALABLILITYHIS-MISRA CT-Spec
PartialNetworkingAftertreatment
QualificationHazard Analysis
ValidationPDU Router
Tool chain Ready
ConsultingDiagnostics&
Hardware ASAM PortabilityDiagnostics MBD ASAM Validation
ECUAUTOSAR Consulting
DoIP
hardware
Efficient ECU
MBD
ISO 14229
Tool Qualification
ISO 15765 Training ConfigurationLegacy to MBD CT-Spec MBD Mode Management Testing CoE
Network Management
Validation R 3.x
drivers
OTXCT Specs
ASAM
MBD Consulting
eNOSMCAL
ECUIn-vehicle CT BSW Stack
R 3.x ODXdriversMigration
BSWStackhardware
ECUR 4.xODXeNOS Scalablility
CT ConsultingMBD ASAM
BSWStackportinghardwareECULINdriverseNOS
AUTOSAR
ECU R 3.x In-vehiclenetwork
CT Specs eNOS
drivers ECU
Migration
MBD
ValidationISO15765Optimization
GatewayScalablilityCT-SpecMigration
DoIP
Management ECURisk Assessment COM Bootloader CT-SpecISO 26262 MBD
MCAL Risk Assessment OSEKOSEK
NetworkVCI
AUTomotive Open System ARchitecture
Source:Google
Website : www.ancitconsulting.comEmail : [email protected]| Contact : +919787400605
Speaker
Dr.B.Kaarthick,Director-R&D, ANCIT
16+ years of experience in Research
Products
ABOUT ANCIT
Next Generation Tooling and Engineering Service Provider for Automotive and Aerospace Industry
Custom Tool DevelopmentProduct Development
Consulting Services Training Services
Awarded as One of the Top 10 Innovators of India in 2016By DST, Government of India
Motive of the WEBINAR
Agenda
• Why AUTOSAR?
• AUTOSAR Layered Architecture
• Design and Communication of AUTOSAR Software Components
Why AUTOSAR ?
.
Why AUTOSAR ?
Source:google
Automotive Industry coping up with increasing complexity• One of the biggest problems faced by the Automotive Companies was that the software must
often be rewritten from scratch when hardware is changed.
• BSW Standardisation: AUTOSAR standardised the BSW system. This provides an opportunity for the software developers to now focus on customer features and functionalities, thereby increasing the competitive value. OEM will prefer to pay only for Application Software but not for the BSW.
• Hardware Abstraction: AUTOSAR provides hardware abstraction i.e., AUTOSAR provides a software module called as Microcontroller Abstraction Layer (MCAL) that makes the Basic Software (BSW) and the application layer independent of the the Microcontroller. The software developer can now focus on building the application than on worrying about configuring the micro controller.
Why AUTOSAR?
• Reusability of functions: across vehicle networks and across OEM boundaries. One of the biggest challenges faced by the OEM was when an OEM wanted to add a function to an existing ECU it required a lot of effort. With the introduction of AUTOSAR this large effort when reusing functions has been reduced. Partitioning and relocation of functions has also been made possible with the introduction of AUTOSAR.
• Standardization of exchange formats: Before AUTOSAR every supplier to the OEM developed products in an ad-hoc mode. This created a lot a compatibility issues as OEM’s work with different suppliers for different products. AUTOSAR is working on standardising the specification of exchange formats. This allows an opportunity for seamless integration among different products from different suppliers. Interfaces has been standardised.
Why AUTOSAR?
.
Why AUTOSAR?
Organizations can focus on specializations. For instance, ANCIT can focus on building great Airbag application software. OEM can buy application from ANCIT, BSW from BOSCH and microcontroller from Infineon.
AUTOSAR Layered Architecture
MICROCONTROLLER
MICROCONTROLLER ABSTRACTIONLAYER
RUN TIME ENVIRONMENT
APPLICATION LAYER
SERVICES LAYER
ECU ABSTRACTIONLAYER COMPLEX DRIVERS
AUTOSAR Layered Architecture
BASIC
SOFTWARE
Complex Drivers
Microcontroller
Microcontroller Drivers
Memory Drivers
I/O Drivers
I/O Hardware Abstraction
Memory Hardware
Abstraction
Memory Services
System Services
Onboard Device
Abstraction
Wireless Communication
Drivers
Communication Hardware
Abstraction
Off-board Communication
Services
Application Layer
Runtime Environment
The Basic Software Layers are further divided into functional groups. Examples of Services are System, Memory and Communication Services.
Crypto Drivers
Crypto Hardware
Abstraction
Crypto Services
Communication Drivers
Communication Services
Wireless Communication HW Abstraction
Basic Software
AUTOSAR Basic Software Module
AUTOSAR has defined a set of BSW modules. They are responsible for different tasks:
Operating System
Access to non volatile memoryCommunication via CAN, LIN, FlexRay and Ethernet Handling the diagnosticsAccess to I/O portsSystem services like ECU state management
In addition, so-called Complex Device Drivers can be integrated into an AUTOSAR ECU. They are used to access the features of the ECU, which are not covered by the standard BSW of AUTOSAR.
• The Microcontroller Abstraction Layer is the lowest software layer of the Basic Software.
• It contains internal drivers, which are software modules with direct access to the µC and internal peripherals.
TaskMake higher software layers independent of µC
PropertiesImplementation: µC dependentUpper Interface: standardized and µC
independent
Microcontroller
Microcontroller Abstraction Layer
ECU Abstraction Layer
Microcontroller Abstraction Layer
• The ECU Abstraction Layer interfaces the drivers of the Microcontroller Abstraction Layer. It also contains drivers for external devices.
• It offers an API for access to peripherals and devices regardless of their location (µC internal/external) and their connection to the µC (port pins, type of interface)
TaskMake higher software layers independent of
ECU hardware layout
PropertiesImplementation: µC independent, ECU hardware
dependentUpper Interface: µC and ECU hardware
independent
Microcontroller
ECU Abstraction Layer
ECU Abstraction Layer
Microcontroller Abstraction Layer
The Complex Drivers Layer spans from the hardware to the RTE.
TaskProvide the possibility to integrate special purpose
functionality, e.g. drivers for devices:Ø which are not specified within AUTOSAR,Ø with very high timing constrains orØ for migration purposes etc.
PropertiesImplementation: might be application, µC and ECU
hardware dependentUpper Interface: might be application, µC and ECU
hardware dependent
Microcontroller
Microcontroller Abstraction Layer
Complex
Drivers
25
ECU Abstraction Layer
Complex drivers Layer
The Services Layer is the highest layer of the Basic Software which also applies for its relevance for the application software: while access to I/O signals is covered by the ECU Abstraction Layer, the Services Layer offers:
Ø Operating system functionalityØ Vehicle network communication and
management servicesØ Memory services (NVRAM management)Ø Diagnostic Services (including UDS communication,
error memory and fault treatment)Ø ECU state management, mode managementØ Logical and temporal program flow monitoring
(Wdg manager)
TaskProvide basic services for applications, RTE and
basic software modules.PropertiesImplementation: mostly µC and ECU hardware
independentUpper Interface: µC and ECU hardware independent
Complex
Drivers
Microcontroller
Microcontroller Abstraction Layer
Services Layer
26
ECU Abstraction Layer
ECU Abstraction Layer
• The RTE is a layer providing communication services to the application software (AUTOSAR Software Components and/or AUTOSAR Sensor/Actuator components).
• Above the RTE the software architecture style changes from “layered“ to “component style“.
• The AUTOSAR Software Components communicate with other components (inter and/or intra ECU) and/or services via theRTE.
TaskMake AUTOSAR Software Components independent
from the mapping to a specific ECU.
PropertiesImplementation: ECU and application specific
(generated individually for each ECU)Upper Interface: completely ECU independent
Microcontroller
Microcontroller Abstraction Layer
AUTOSAR Runtime Environment (RTE)
Services Layer Complex
Drivers
27
RTE Layer
ECU Abstraction Layer
The Application Layer contains the SWCs, which realize the application functionality of the ECU. This is the piece of software that the OEM is ready to pay . Sometimes the OEM build some of the applications to protect their IP.
Application Layer and RTE
Microcontroller
Microcontroller Abstraction Layer
AUTOSAR Runtime Environment (RTE)
Services Layer Complex
DriversECU Abstraction Layer
Application Layer
.
CAN STACK Architecture
Application
CANSTACKCAN
DRIVERCAN
HARDWAREThe CAN driver enables the access to hardware resources, for the upper software layers. It also offers access to the hardware API, to the application layer.
• manages sleep/wake up functionality.• CAN Bus Interface Layer carries out all hardware
tasks, related to the flow of data to the upper layer modules of the CAN software stack.
• UDS Software Stack to manages the diagnostics• Flash Bootloader Application for ECU
Reprogramming..• segmenting the data, if the size of the data frame is
more than 8 Bytes.
Simplified Component View
ECU-Hardware
AUTOSAR Runtime Environment (RTE)
Actuator Software
Component
AUTOSARInterface
Application Software
Component
Sensor Software
Component
Application Software
ComponentAUTOSARSoftware
Basic SoftwareStandardized
Interface
AUTOSARInterface
AUTOSARInterface
AUTOSAR
............Interface
Microcontroller Abstraction
StandardizedAUTOSARInterface
Services
Standardized Interface
ECUAbstraction
AUTOSARInterface
Standardized Interface
Complex Device Drivers
AUTOSARInterface
Standardized Interface
Communication
Standardized Interface
Standardized Interface
Operating System
StandardizedInterface
AUTOSARSoftware
Component
Interface
Standard Software
Interfaces:VFB & RTE
relevant
RTErelevant
BSWrelevantPossible interfaces
insideBasic Software
(which are not specified
within AUTOSAR)
AUTOSAR Methodology
‘
Design and Communication of Software Components
SeatHeatingControl
SeatHeatingControl with seven software components
SeatHeatingControl
• SeatHeatingControl
• Input:• Whether a Passenger is sitting on the seat
”SeatSwitch”• Setting of the seat temperature dial “Setting”• Some information from a central power management
system “Power Management”
• Output:• DialLED associated with the seat temperature
“DialLED”• Heating Element to be Turned ON
“HeatingElement”
3
Sender-Receiver RPORT
The Component reads/consumes values
of data-elements
Client - Server PPORT
The Component provides operation
defined in the interface
Client – ServerRPORT
The Component requires operation
defined in the interface
Sender - ReceiverPPORT
The Component provides values of data-
elements
Sender Receiver Interface
Client Server Interface
Communication between SWCs takes place chiefly over two kinds of ports, Client/ Server ports where server is a provider of a service and the client is a user of a service and Sender/ Receiver ports where a sender distributes information to one or several receivers in synchronous as well as asynchronous environment.
The implementation architecture of SWC is formally defined in terms of so-called runnable entities. They correspond to procedures and are executed on a specific event such as a periodic activation or reception of new input value.
During system design phase the SWCs can be integrated with their environment (e.g. hardware, driver, OS, etc) based on Virtual Functional Bus (VFB).
Atomic Software Component- Smallest software component which will remain in one ECU only.Cannot be broken between ECUs.
Design and Communication of software Components
Atomic Component and Runnables
AUTOSAR Supports Multiple Instantiation
two instances of the “SeatHeatingControl” component-type are used to control the left front seat, respectively the right front seat. These components will typically have their own separate internal state (stored in separate memory locations) but might for example share the same code
AUTOSAR System View
Simplified Component View
ECU-Hardware
AUTOSAR Runtime Environment (RTE)
Actuator Software
Component
AUTOSARInterface
Application Software
Component
Sensor Software
Component
Application Software
ComponentAUTOSARSoftware
Basic SoftwareStandardized
Interface
AUTOSARInterface
AUTOSARInterface
AUTOSAR
............Interface
Microcontroller Abstraction
StandardizedAUTOSARInterface
Services
Standardized Interface
ECUAbstraction
AUTOSARInterface
Standardized Interface
Complex Device Drivers
AUTOSARInterface
Standardized Interface
Communication
Standardized Interface
Standardized Interface
Operating System
StandardizedInterface
AUTOSARSoftware
Component
Interface
Standard Software
Interfaces:VFB & RTE
relevant
RTErelevant
BSWrelevantPossible interfaces
insideBasic Software
(which are not specified
within AUTOSAR)
API CALLS
Ports
Syntax & Semantics
AUTOSAR Interfaces
AUTOSAR Interfaces are used in defining the ports of software-components and/or BSW modules. Through these ports, software-components and/or BSW modules can communicate with each other AUTOSAR makes it possible to implement this communication between Software-Components and/or BSW modules either locally or via a network.
The AUTOSAR Interface is a generic interface which is derived from the ports of a SWC. AUTOSAR Interfaces are provided by the RTE and serve as interface between SWCs or between SWCs or between a SWC and the ECU firmware (IO HW and Complex Drivers). Via these interfaces, a SWC can e.g. read an input value or write an output value.
The Standardized AUTOSAR Interface is an "AUTOSAR Interface” whose syntax and semantics are standardized in AUTOSAR. Such interfaces are used by the SWCs to access AUTOSAR Services, which are provided by BSW modules of the Service Layer like the ECU manager or the diagnostic event manager.
The Standardized Interface is an interface, which is predefined by the AUTOSAR standard as API in C language. It is used between BSW module within an ECU, between RTE and Operating System (OS), or between RTE and the Communication Layer.
AUTOSAR Summary
Future Plans
Next Webinar:Application Software Component Development
You will learn:• How to create an system file (arxml) • How to build a system level application software component • Generate <*.c> and <*.h> file• Build the ASWC <*.c>
Date: Sep 3, 2020 Time: 3pm
To create an AUTOSAR Learning Group in India[in collaboration with SemiCon, Tier 1, OEM , Service Providers and Universities]
ANCIT will continue to deliver Series of WebinarsCreate AUTOSAR Learning Kit & Easy to Learn AUTOSAR StackTools and Automation Support for AUTOSAR Development
EDB EDITOR
EDB Editor
Available for download from: August 15,2020 Its FREE!!!!
Features:
• Create the electrical database in the form of excel file.
• Signals and node addition or removal.
• Message event or cyclic time conversion.
• Add or remove message in to the database file(excel)
• Edit existing database files. • Convert the one format file(excel)
to other(vector dbc/arxml). ex: vector database to .arxml standard & vice versa. Conversation made as per new file conversion standard.
1. easness to create the electrical database in the form of excel file. 2. easiness on signals and node addition or removal. 3. easiness on message event or cyclic time conversion. 4. easiness to add or remove message in to the database file(excel)5. the above mention the feature can be added or removed on the already exist database file. 6. easiness to convert the one format file(excel)to other(vector dbc/arxml). example: vector database to arxml standard and vice versa. it's required becuse
of due to huge autosar adaptation is taken place in the automotive industry and development and testing tools are made and understandable by old format. 7. Conversation will be made as per new file conversion standard and quality will be assured.
EDB EDITOR FEATURES
Registered Office4/1, Sri Krishna Villas,1st Cross, Kongu Nagar, RamanathapuramCoimbatore,TN, IndiaPin : 641045Ph : +91-422-6461778
Consulting Office#28, Shankar Mutt Road,Bangalore, KA, India.Pin : 560004Ph : +91-80-41244277/+91-80-23163244
In GermanyPW-techUnterhaunstädter Weg 385055 Ingolstadt, Germany
In USFour Colors Technology LLC3828 Tonsley PlHigh Point, NC 27265
| Website : www.ancitconsulting.comEmail : [email protected] Contact : +919787400605
Our Locations