3
peripherals
3.1 IO hardware abstraction
IO hardware abstraction is part of the ECU abstraction layer. The goal of the IO hardware abstraction module is to enable data to be transmitted through the RTE
output without any dependence on ECU hardware. This means that the software component designer does not need to know more about how signals affect
affect the physical layer. Therefore, this module is ECU-specific.
This is mainly achieved by mapping ECU signals to IO abstract ports. The module IO hardware abstraction is provided for initial
A module that initializes the entire IO hardware abstraction.
The figure below shows the IO hardware abstraction block. It sits on top of the MCAL driver. That is to say, the IO hardware abstraction module needs to adjust
On-chip devices are managed using the driver API. The configuration of the MCAL driver depends on the ECU to be provided by the IO Hardware Abstraction Module
The quality of the signal. For example, notifications are required when relevant changes occur on the pin layer (rising edge, falling edge). system
The designer has to configure the MCAL driver to allow notification for a given signal. Notifications come from the driver, and in the IO hard
It is processed in the piece abstract module.
3.2 ADC driver
The ADC driver initializes and controls the analog-to-digital conversion unit inside the microcontroller. The driver contains a series of basic functions
function. In order to be able to perform frequency analysis of signals (for example, fast Fourier transform) in some special applications, it is necessary to
It is necessary to strengthen the function of streaming access.
The ADC driver provides the following services:
·
Access modes for signal value results
·
streaming access.
Typically, conversion requests for ADC channels are controlled through ADC channel groups. Channel groups can operate on continuously variable
switching mode or one-shot switching mode.
Conversion processing and interaction: At the same time, the ADC driver manages more than one group configured for different conversion modes.
Conversion process:
Typically, conversion requests for ADC channels are controlled through ADC channel groups. A group can run in continuous turn
conversion mode or one-shot conversion mode. The trigger conditions for the one-shot conversion mode are also configured and controlled.
If the channels operate in different modes (for example, in normal operation with continuous switching mode, at a certain point in time
For special conversions using one-shot or command-based conversions), the channels must be assigned to
of multiple groups.
In order to change the mode of operation of a channel shared between groups, the application must stop any current access to the group containing the specified channel.
Convert before, and then start the conversion of a new group containing the specified channels.
In order for an application to perform an immediate conversion at any time, an on-command conversion is defined. it
You must suspend the group transition and then reactivate it after the commanded transition activity is complete.
3.3 DIO driver
The DIO driver provides port- and channel-based, read and write access to internal general-purpose I/O breakpoints. Here read and write and
are not buffered. The basic behavior of this driver is synchronous.
The DIO driver provides services for reading and writing to the following facilities:
·
DIO channel (pin)
·
DIO port
·
DIO channel group
The behavior of these services is synchronous. The module works on pins and ports, and is configured by the PORT driver.
Therefore, the port structure is not configured and initialized in the DIO driver.
Port driver module:
Many ports and port pins are assigned to various functions by the port driver module, such as
·
Regular I/O
·
ADC
·
SPI
·
PWM
DIO drivers abstract access to microcontroller hardware pins. Additionally, it is able to group these pins.
The DIO driver provides the following services:
·
Modifies the level of the output channels of a port or channel group one by one.
·
Reads the ranks of the input and output channels of a port or channel group one by one.
All read and write services in a DIO driver must be reentrant. The reason is: these DIO drivers can be used by different
Layer handler or driver access. These upper-level modules can access drivers in parallel.
3.4 GPT driver
GPT drivers allow for one-shot or persistent timer notifications. This module uses the general-purpose timer's hardware timing pass
Road, so for the operating system or other basic software modules (in such modules, the OS warning service has too many developments)
pin) provides precise, short-term timing.
The GPT driver provides services for starting and stopping function timing instances (channels) in the hardware timing module. it can
Able to generate single timeout periods as well as repeated timeout periods. If a notification must be called, then when the requested timeout period
When expired, the user will be able to configure it. Notifications can be enabled or disabled at runtime.
Queries can be made whether it's the relative time elapsed since the previous notification occurred, or the time remaining until the next notification.
Note that the GPT driver only generates time bases and does not serve time counters. This function is provided by another module
(ICU driver).
The GPT driver can be used to wake up the ECU regardless of the expiration of the predefined timeout period. Schema switching service converts GPT
The driver transitions between normal operation and sleep mode.
The driver does not provide timeout periods beyond those limited by clock sources, prescalers, and watch registers
the maximum value. The user must take care of this.
3.5 ICU driver
The ICU driver controls the input capture unit of the microcontroller. It provides the following features:
·
Periodic, low-end, high-end time measurement
·
Edge Detection and Notification
·
edge count
·
edge timestamp
·
wake up interrupt
For signal edge detection, it is necessary to use the edge detector of the capture compare unit or the interrupt control of the external time
device.
For signal measurements, a capture timer and at least one capture register are required.
The ICU modulates the PWM signal, counts pulses, measures frequency and duty period, generates simple interrupts and
Wake up interrupt.
The ICU driver provides the following services:
·
Signal Edge Notification
·
Control Wakeup Interrupt
·
Periodic signal time measurement
·
Edge timestamps, which can be used to acquire aperiodic signals
·
edge count
To ensure data consistency, reentrant code should be provided.
time unit beat
In order to get the time from the register value, one needs to know the oscillator frequency, prescaler, etc. Because these settings are in the
generated in the MCU module or in other modules, it is not possible to calculate these times. Therefore, the conversion between time and beat is
responsible by the upper echelons.
3.6 MCU driver
MCU driver provides basic microcontroller initialization, power down, reset and other MCAL software module needs
Services for microcontroller-specific functions. Initialization services provide flexibility and, in addition to startup code, also provide
Application related MCU initialization. The startup code is completely MCU-specific. MCU driver directly accesses microcontroller
controller hardware, which resides in the Microcontroller Abstraction Layer (MCAL).
Features of the MCU driver:
·
Initialize MCU clock, PLL, clock prescaler and MCU clock distribution
·
Initialize RAM components
·
Activate microcontroller power-saving mode
·
Activate microcontroller reset
Also, there is a reason to provide a service to get a reset from the hardware.
MCU drives microclock and RAM initialization to provide MCU services. In an MCU configuration set, the MCU-specific
Clock (for example, PLL settings) and RAM (for example, segment base address and size) settings must be configured.
3.7 Port driver
This module initializes the entire port structure of the microcontroller. Many ports and port pins can be assigned to different functions
can, for example:
·
General purpose I/O
·
ADC
·
SPI
·
SCI
·
PWM
For this reason, a general configuration and initialization of this port structure must be performed. The configuration and use of these port pins
The use is dependent on the microcontroller and ECU.
This module should provide services for initializing the entire port structure of the microcontroller. Many ports and port pins can
are assigned to various functions. For this reason, there must be full configuration and initialization of the port structure. these ends
The configuration and mode of the port pins are microcontroller and ECU dependent.
The port driver module should complete all configuration and initialization of the port structure, which is used in the DIO driver
in the module. Therefore, DIO drivers work on top of pins and ports, and it is up to the port driver to configure it. ports and ports
The configuration order of the pins is the responsibility of the configuration tool.
Port drivers should be initialized before using DIO functions. Otherwise the DIO driver produces undefined behavior.
Atomicity of port access: Port drivers should provide
Provides atomic access to ports.
3.8 PWM driver
Each PWM channel is connected to a hardware PWM belonging to the microcontroller. The driver provides initialization and control
PWM service inside the microprocessor. The PWM module generates pulses with different pulse widths.
3.9 SPI handler / driver
The SPI bus is a master-slave multi-node bus system. The master node sets chip select (CS) to select a slave node for
data communication. SPI has a 4-wire synchronous serial interface. Use chip select lines to activate data communication.
The following SPI modules provide channel-based read, write, and transfer access to various devices on the SPI bus. SPI communication
Roads represent data elements (
8 to 16 bits). These channels may be combined sequentially and cannot be interrupted. Channels have a static configuration defining baud rate, chip select, etc. SPI devices usually consist of the SPI hardware unit used and the associated chip select line
to identify. This module can be used as a SPI master node.
The functional scope of this software module should be statically configurable to adapt as much as possible to the timing needs of each ECU.
want. That is, SPI accesses such as synchronous, asynchronous, or both can exist in the ECU. therefore,
Two SPI drivers can exist, but only one handles the interface.
The SPI handler/driver provides services to read and write to devices connected via the SPI bus. It provides
required mechanism to configure the on-chip SPI peripheral.
A monolithic SPI handler/driver contains both processing and driver functions. Its main goal is to take full advantage of each microcontroller
The characteristics of the controller make it possible to rely on the optimization of the static configuration to adapt as much as possible to the needs of the ECU.
3.10 Watchdog Interface
The internal watchdog driver controls the MCU's internal watchdog timer. It provides trigger functions and mode selection services.
External Watchdog Driver
The external watchdog driver controls the external hardware watchdog. It provides trigger functions and mode selection services. it has and inside
Same function scope as watchdog driver.
If more than one watchdog device and watchdog driver are used in one ECU (for example, internal software watchdog
watchdog and external hardware watchdog), this module enables the watchdog manager to select the appropriate watchdog driver, and to see
Watchdog device.
The watchdog driver interface provides uniform access to the services of the underlying watchdog driver, such as mode transitions and triggers. have
The device index selects the appropriate watchdog device. Behavior (synchronous/asynchronous/timing) of watchdog-driven services is protected.
The watchdog driver interface does not add additional functionality to the watchdog driver. The watchdog driver interface is also not slaved to the watchdog
abstraction in nature, such as toggle or window mode, timeout period, etc., that is to say, the driver interface does not hide the underlying layer
Any features of the watchdog driver and watchdog device.
4
AUTOSAR methods, models, tools and conformance testing
4.1 AUTOSAR method
AUTOSAR requires a common technical approach in certain steps of system development. This method is called "AUTOSAR method
method". The "AUTOSAR method" is neither a complete process description nor a business model, and no "angles" are defined in this method.
"role" and "responsibility", and it does not prescribe which activities are to be performed. The AUTOSAR approach is simply a "job
A work-product flow defines the interdependencies of activities in a work-product flow.
The AUTOSAR approach does not define an overall timeline, nor does it define how and when iterations are performed. For example in the department
In system design, the same behavior (i.e., system configuration behavior) is repeated with varying degrees of precision. The first "rough"
configuration and the last "exact" configuration depends on the actual configuration and even the implementation of the ECU.
The figure above shows the process of describing ECU from design to construction and integration using AUTOSAR method.
1. First define the System Configuration Input, select software and hardware components, and identify the overall limitations of the system.
This is the task of system design or architecture. AUTOSAR tends to use information exchange formats (software components,
ECU resources, system constraints) and templates to reduce the formal description of these initial system design decisions. So set
Defining the System Configuration Input means filling in and editing the appropriate template. fill out the template from scratch
Or reuse the template (may also require some changes) depends on the use case. Basically the AUTOSAR approach allows
High reuse of templates.
2. The activity Configure System mainly maps the software components to the ECU regarding resource and timing requirements.
3. The output of Configure System is System Configuration Description. This description includes all
There is system information (such as bus mapping, topology, etc.) and a mapping on which ECU the software components are located.
4. The activity Extract ECU-Specific Information is extracted from the System Configuration Description
Get the information needed for a specific ECU.
5. Then output to ECU Extract of System Configuration.
6. The activity Configure ECU adds all required information for the implementation such as task scheduling, required BSW (base
basic software) modules, configuration of BSW, assignment of runnable entities in tasks, etc.
7. The result of active Configure ECU will be output to ECU Configuration Description, which is responsible for receiving
Collects all local information about a specific ECU. From this information the executable for that particular ECU can be built
software.
8. In the last step, the activity Generate Executable according to from ECU Configuration Description
The information obtained in generates executable software. This step usually involves generating code (eg for RTE and BSW)
into code), compile the code (compile the grown code or compile the source code of the software component), convert all compiled
The code is concatenated into executable software.
9. Get the executable ECU software.
During these brief introductions to the AUTOSAR approach, there is also the need to integrate the software components into the overall system,
For example, generate component API, implement component functions, etc. Although these are not represented in the diagram above, the implementation of software components
Now it is more or less independent of the configuration of the ECU.
4.2 AUTOSAR model
4.2.1 Origin
AUTOSAR allows the precise and formal description of all aspects of a distributed system consisting of embedded controllers and corresponding software execution units to establish a very flexible yet stable and reliable software engineering life cycle.
This description ranges from high-level interface requirements of software components to low-level byte limits for specific bus messages.
system. The information that needs to be obtained from the various descriptions is determined by the different work packages in AUTOSAR. And these descriptions are
AUTOSAR model.
AUTOSAR model belongs to a subset of UML2.0, which is a simplification of UML2.0 metamodel. Because in UML2
The highly modular structure and the excessive use of redefinition of classes, attributes, and associations sometimes make it difficult to use one or two diagrams to show a certain
Specific aspects while maintaining clear readability. Therefore, the UML2.0 metamodel is simplified here to only include some elements.
4.2.2 Terminology
4.2.3 Metamodel system
The complete AUTOSAR template metamodel system has five layers, as shown in the figure below:
M0 layer: AUTOSAR object
This is an implementation of an AUTOSAR system: a real ECU executes a software image containing the wiper control software.
M1 layer: AUTOSAR model This meta-level model is built by AUTOSAR end users (automotive engineers). defined by them as "rain
Brush" software components and a series of interfaces to other software components, etc. At this level the AUTOSAR system is subdivided
into reusable components and specific instances.
M2 layer: AUTOSAR metamodel
This layer defines the "vocabulary" that will later be used by AUTOSAR end users, for example, this layer defines the
In AUTOSAR there is an entity named "Software Component" and another entity named "Port". between these entities
Both linkage and semantics are part of the overall model.
M3 : UML profile of AUTOSAR template
The templates for the M2 layer are built from the metamodel defined by the M3 layer. As discussed earlier, this is UML plus a
A specific UML profile to better support template modeling work. Strictly speaking, the template on the M2 layer is still UML
instance, but also uses the template profile.
M4 : meta object facility
For conceptual completeness, OMG puts MOF on the last meta layer. Because MOFs are defined as anti-
Injective, so no further meta-layers are needed.
4.3 AUTOSAR tools
"AUTOSAR authoring tools" means all AUTOSAR
Tool for XML description (XML representation of AUTOSAR models). These models are generated from the following templates:
1. Software component templates,
2. ECU resource template,
3. AUTOSAR system template.
The AUTOSAR authoring tool consists of several important aspects, as shown in the figure below.
A feature definition for an authoring tool
"Characteristic Definitions for Authoring Tools" proposes a step-by-step implementation of the part of the AUTOSAR overall concept regarding exchange descriptions,
That is, software component templates, ECU resource templates, and system templates. On the basis of the first implementation, define AUTOSAR
AUTOSAR authoring tool for a subset of templates. Collaborative work of B authoring tools
"Collaboration of authoring tools" focuses on those issues that may arise when exchanging AUTOSAR models between different tools.
The problem. This document first describes some basic concepts of data exchange, and then briefly outlines strategies to solve these problems.
slightly.
C Behavioral Model Interaction
"Interaction of Behavioral Models" lists the use cases of behavioral models in AUTOSAR. and identify the behavioral model
Part of the AUTOSAR metamodel.
D graphic symbol
Graphical Symbols defines the AUTOSAR Graphical Symbols for the AUTOSAR Authoring Tool. For example, the document is a graphic
Modeling CompositionTypes provide an exhaustive schema. These graphic symbols should be used as the implementation of AUTOSAR authoring
Tool guide.
4.4 Conformance Test
The purpose of the AUTOSAR conformance test is to verify whether the product conforms to the AUTOSAR specification. These products
Products need to demonstrate compliance with the AUTOSAR standard in terms of interoperability, reusability/portability, and scalability.
Because AUTOSAR is an open standard, all final specifications are part of the standard.
This document focuses on several interrelated paths necessary to demonstrate AUTOSAR compliance for a particular product. tested
The complexity of the process should be as low as possible, but the most appropriate test should be determined according to the relationship between the supplier and the customer
plan.
The roles in conformance testing are:
（1）
AUTOSAR (maintains the standard, monitors the use of the AUTOSAR specification),
（2）
Conformance Test Agency (divided into first-party CTA and third-party CTA, the main task
is to provide test packages, perform tests, provide support and certification services),
（3）
Product Supplier (develop and test products)
5
Summarize
The proposal of AUTOSAR has a great impact on the development of automotive electronic software, which can be seen from the following aspects
out:
（1）
Impact on OEMs
The introduction of AUTOSAR is most beneficial to OEMs. Giving them more flexibility to have software procurement and control
With greater rights, software providers will gradually increase, giving them more choices; at the same time, the openness of software systems
As a result, the quality supervision of the software will be improved accordingly. These are undoubtedly beneficial and harmless to them.
（2）
Impact on component suppliers
The impact on component provision must be analyzed from two perspectives. From a technical point of view, the development of software technology has a great impact on components
The efficiency gains that providers bring are unquestionable. Enhanced software portability, availability, maintainability, etc., for
The benefits to software developers are enormous.
From a commercial point of view, the proposal of open software standards is beneficial to all software providers. But at the same time, the theory
Generally speaking, the previous monopoly mode of some software providers has been broken with the proposal of this open system. New markets will be opened
Open, competition and opportunities coexist. Traditional component providers still have an advantage in the market due to their base build-up, but new providers
Businesses will have more opportunities than before.
（3）
Impact on Chip Providers
The impact on chip providers is common, mainly to provide some support work. Since the development of basic software still needs
It needs the strong support of the chip provider, so the chip provider will spare no effort to provide support for this standard. Although non-nuclear
The core business, but if the support is completely given up, the market share may be affected to some extent.