Specification of FlexRay Transceiver Driver (`FlexRayTransceiverDriver`)¶

属性	值
平台	CP
类别	SWS — 软件模块规范（Software Specification）
UID	074
规范版本	R26-11

本地文件¶

规范 PDF: F:\Work\Standards\01_Sources\CP_SWS_FlexRayTransceiverDriver_074\AUTOSAR_CP_SWS_FlexRayTransceiverDriver.pdf
ARXML 模型: F:\Work\Standards\01_Sources\CP_SWS_FlexRayTransceiverDriver_074\AUTOSAR_CP_SWS_FlexRayTransceiverDriver.arxml
纯文本全文: F:\Work\Standards\01_Sources\CP_SWS_FlexRayTransceiverDriver_074\zzgen\CP_SWS_FlexRayTransceiverDriver.complete.txt

文档简介¶

This specification describes the functionality, API and the configuration for the AUTOSAR Basic Software module FlexRay Transceiver Driver.

The FlexRay Transceiver is a hardware device, which mainly transforms the logical 1/0 signals of the \muC ports to the bus compliant electrical levels, currents and timings.

Within an automotive environment, there is currently only one single physical layer specification for FlexRay. In addition, the transceivers could be able to detect electrical malfunctions like a break in the cable harness, ground offsets (a certain ground shift is tolerated), or bus collisions. Depending on the interface, they flag the detected error summarized by a single port pin or very detailed via SPI. The FlexRay Transceiver Driver has the capability of wake up via bus and the usage is optional. Some transceivers also support power supply control. Future markets will probably see a lot of different wakeup/sleep and power supply concepts.

One FlexRay Interface accesses several FlexRay Transceivers (FlexRay Transceiver Type X .. Z) using one or several FlexRay Transceiver Driver(s) (FrTrcv Driver Vendor A...C) from different vendors.

A zero based index (FrTrcv_TrcvIdx) identifies the transceiver within the context of the transceiver driver. E.g., FlexRay transceiver A of FlexRay transceiver type Z is addressed by the index 0, FlexRay transceiver B by the index 1 in the example in the Figure above. A zero based index (FrTrcv_BranchIdx) identifies the branch within the context of the transceiver.

模块依赖¶

Module	Dependencies
FrIf	The FlexRay Interface controls the state of the FlexRay transceivers via the FlexRay Transceiver Driver
Det	The FlexRay Transceiver Driver informs the Default Error Tracer on errors
Dem	Dem gets production error information from FlexRay Transceiver Driver.
Dio	Dio module is used to access FlexRay transceiver hardware connected via ports.
EcuM	EcuM gets wake up event information from FlexRay Transceiver Driver if supported by hardware.
RTE	The FlexRay Transceiver Driver main function may be scheduled by the by the RTE.
Spi	Spi module is used to access FlexRay transceiver hardware connected via SPI.

Please be aware although this documentation of the FlexRay transceiver consumes more of 50 pages of paper, in the end it will still resolve to setting a few bits in RAM and transferring them via SPI or setting a few port pins. This can be VERY small code (e.g. inline functions) in case post build time configuration is not required.

If an upper layer wants to call any FlexRay transceiver specific FlexRay API, knowledge which FlexRay transceiver driver it has to call for a specific communication FlexRay transceiver is not required. Only a mapping (=knowledge) generated by configuration is required!

Here is an example:

章节详细内容¶

1. 简介与功能概述¶

原文标题：Introduction and functional overview

This specification describes the functionality, API and the configuration for the AUTOSAR Basic Software module FlexRay Transceiver Driver.

The FlexRay Transceiver is a hardware device, which mainly transforms the logical 1/0 signals of the \muC ports to the bus compliant electrical levels, currents and timings.

Within an automotive environment, there is currently only one single physical layer specification for FlexRay. In addition, the transceivers could be able to detect electrical malfunctions like a break in the cable harness, ground offsets (a certain ground shift is tolerated), or bus collisions. Depending on the interface, they flag the detected error summarized by a single port pin or very detailed via SPI. The FlexRay Transceiver Driver has the capability of wake up via bus and the usage is optional. Some transceivers also support power supply control. Future markets will probably see a lot of different wakeup/sleep and power supply concepts.

One FlexRay Interface accesses several FlexRay Transceivers (FlexRay Transceiver Type X .. Z) using one or several FlexRay Transceiver Driver(s) (FrTrcv Driver Vendor A...C) from different vendors.

2. Goal of FlexRay 收发器驱动¶

原文标题：Goal of FlexRay transceiver driver

This document specifies interfaces and sequence models, which apply to current and future FlexRay transceiver hardware devices. The FlexRay transceiver driver abstracts the usage of FlexRay transceiver hardware chips. It offers a hardware independent interface to the higher layers. The FlexRay Transceiver Driver abstracts from the ECU layout by using the APIs of the MCAL layer to access FlexRay Transceiver hardware.

3. Explicitly uncovered FlexRay 收发器 Functionality¶

原文标题：Explicitly uncovered FlexRay Transceiver Functionality

The FlexRay Transceiver Driver software specification supports all transceivers conformant to .

4. Active Stars¶

The FlexRay Transceiver driver supports active star topologies. The host disables and enables branches of active stars. Configuration defines the timing of active stars according to and provides topology information of branches.

5. 缩略语¶

原文标题：Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the FlexRay Tranceiver Driver module that are not included in the .

Abbreviation / Acronym:	Description:
\muC	Microcontroller
Active Star (Network)	Star topology networks consist of one ore more active central nodes which rebroadcast(s) all transmissions received from a branch to all other branches on the network.

All peripheral nodes may thus communicate with all others by transmitting to, and receiving from, the central node(s) if they are located on another branch.

On detection of the failure of a branch the active star will isolate its peripheral nodes from all other branches resulting in fault confinement | API | Application Programming Interface | |---|---| | AUTOSAR | Automotive Open System Architecture | | BD | Bus Driver | | Branch | Element of an active star network topology sharing (i.e. electrically connected to) the same transmitter and receiver circuit on the physical layer. |

The failure of a branch will result in the isolation of its peripheral nodes by the active star from all other branches resulting in fault confinement.

6. 相关文档¶

原文标题：Related documentation

7. 输入文档与相关标准规范¶

原文标题：Input documents & related standards and norms

8. 相关规范¶

原文标题：Related specification

AUTOSAR provides a General Specification on Basic Software modules , which is also valid for FlexRay Transceiver Driver.

Thus, the specification SWS BSW General shall be considered as additional and required specification for FlexRay Transceiver Driver.

9. 约束与假设¶

原文标题：Constraints and assumptions

10. 限制¶

原文标题：Limitations

The FlexRay Transceiver must provide functionality and an interface, mapped to the operation mode model assumed for the AUTOSAR FlexRay Transceiver Driver. See AUTOSAR FlexRay Transceiver Operation Modes.

Upstream requirements: ⌈ The FlexRay Transceiver Driver shall use the APIs of underlying DIO drivers synchronously. ⌋

⌈ The FlexRay Transceiver Driver should use the APIs of underlying SPI drivers synchronously if possible and asynchronously where required. ⌋

⌈ The FlexRay transceiver requires a LEVEL 2, Enhanced (Synchronous/Asynchronous) SPI Handler/Driver ⌋

Upstream requirements: ⌈ The FlexRay Transceiver Driver shall handle the transceiver-specific timing requirements internally. ⌋

The communication between the \muC and the transceiver is performed via ports or SPI or both. If ports are used, applying values in a predefined sequence and with a given timing to the ports are used to communicate and change the hardware operation modes. These sequences and timings must be handled within the FlexRay Transceiver Driver.

11. 适用的车型领域¶

原文标题：Applicability to car domains

This driver shall be applicable in all car domains using FlexRay for communication.

12. 对其他模块的依赖¶

原文标题：Dependencies to other modules

Module	Dependencies
FrIf	The FlexRay Interface controls the state of the FlexRay transceivers via the FlexRay Transceiver Driver
Det	The FlexRay Transceiver Driver informs the Default Error Tracer on errors
Dem	Dem gets production error information from FlexRay Transceiver Driver.
Dio	Dio module is used to access FlexRay transceiver hardware connected via ports.
EcuM	EcuM gets wake up event information from FlexRay Transceiver Driver if supported by hardware.
RTE	The FlexRay Transceiver Driver main function may be scheduled by the by the RTE.
Spi	Spi module is used to access FlexRay transceiver hardware connected via SPI.

Please be aware although this documentation of the FlexRay transceiver consumes more of 50 pages of paper, in the end it will still resolve to setting a few bits in RAM and transferring them via SPI or setting a few port pins. This can be VERY small code (e.g. inline functions) in case post build time configuration is not required.

If an upper layer wants to call any FlexRay transceiver specific FlexRay API, knowledge which FlexRay transceiver driver it has to call for a specific communication FlexRay transceiver is not required.

13. 上层 layer：¶

原文标题：Upper layer:

"Set all transceivers of cluster C (within a single ECU) to state NORMAL"

FrIf (has cluster knowledge): Cluster C uses CC Y which is connected to Transceiver (Trcv) Xa (FlexRay transceiver A) and Xb (FlexRay transceiver B)

"Set transceivers Xa and Xb to state NORMAL"

FrTrcv (has transceiver driver knowledge, assuming different drivers):

transceiver Xa is the 1st device within driver D1

transceiver Xb is the 3rd device within driver D2

"set Xa to normal via D1(1st device)"

"set Xb to normal via D2(3rd device)"

FlexRay Transceiver Driver FrTrcv D1 (has Transceiver HW knowledge):

NORMAL for 1st device is achieved by setting Dio signal S1 to HIGH and DIO Signal S2 to HIGH

"DIO set S1 and S2 to HIGH"

ECU Abstraction Layer (has ECU layout information):

Signal S1 is mapped to DIO channel C7

Signal S2 is mapped to DIO channel C8

DIO (has port/pin knowledge) configuration maps C7 to PORTs.PINn and C8 to PORTt.PINm

set S1 to HIGH via PORTs.PINn ((Dio_WriteChannel(S1, Std_High);)

set S2 to HIGH via PORTt.PINm ((Dio_WriteChannel(S2, Std_High);)

14. 文件结构¶

原文标题：File structure

15. Naming convention for 收发器驱动 implementation¶

原文标题：Naming convention for transceiver driver implementation

Upstream requirements: ⌈ A FlexRay Transceiver Driver implementation may support different FlexRay Transceiver hardware. ⌋

Upstream requirements: ⌈ The is applied for the naming in a way that no FlexRay transceiver hardware specific naming extensions are used.

The following naming convention shall be used as mentioned in :

Driver modules shall be named according to the following rules (only for implementation, not for the software specification):

First the module name has to be listed:

After that the vendor Id defined in the AUTOSAR vendor list has to be given

At last a vendor specific name follows

All parts shall be separated by underscores "_"

This naming extension applies to the following externally visible elements of the module:

File names
API names

Published parameters ⌋

16. 代码文件结构¶

原文标题：Code file structure

The FrTrcv module consists of the following code files:

Upstream requirements: ⌈ FrTrcv.c is the implementation general C file. It does not contain interrupt routines. ⌋

Pre-compile-time configuration Upstream requirements: ⌈ All modules of the AUTOSAR Basic Software, operating on Pre-compile-time configuration data (not to be modified after compile time), shall group and export the configuration data to configuration files.

Module specific configuration header file naming convention:

_Cfg.c

Static configuration is decoupled from implementation. Separation of configuration dependent data at compile time furthermore enhances flexibility, readability and reduces version management as no source code is affected. ⌋

Separate C-Files for pre-compile time configuration parameters Upstream requirements: ⌈ Configuration parameters being stored in memory shall be placed into separate c-files (effected parameters are those from link-time configuration as well as those from post-build time configuration).

Enable the use of different object files. ⌋

17. 头文件结构¶

原文标题：Header file structure

Upstream requirements: ⌈ All AUTOSAR Basic Software Modules shall only import the necessary information (i.e. header files) that is required to fulfill the modules functional requirements. ⌋

Upstream requirements: ⌈ Limit exported information: All AUTOSAR Basic Software Modules shall export only that kind of information in their correspondent header-files explicitly needed by other modules. ⌋

18. 需求追踪¶

原文标题：Requirements Tracing

Requirement	Description	Satisfied by
The Basic Software Module shall be able to initialize variables and hardware in a separate initialization function
All modules of the AUTOSAR Basic Software shall support a tool based configuration
All AUTOSAR Basic Software Modules shall provide configuration rules and constraints to enable plausibility checks
The AUTOSAR SW Components shall provide information about their dependency from faults, signal qualities, driver demands
Optional functionality of a Basic-SW component that is not required in the ECU shall be configurable at pre-compile-time
The scheduling strategy that is built inside the Basic Software Modules shall be compatible with the strategy used in the system
Unique Name of Basic Software Modules
All AUTOSAR Basic Software Modules shall only import the necessary information
All AUTOSAR Basic Software Modules shall only export information needed by other modules
All internal driver modules shall separate the interrupt frame definition from the service routine
Error values naming convention
All Basic Software Modules shall strictly separate error and status information

19. 功能规范¶

原文标题：Functional specification

⌈ The FlexRay Tranceiver Driver shall use the Time service Tm_BusyWait1us16bit to realize the wait time for transceiver state changes. ⌋

20. AUTOSAR FlexRay 收发器 Operation 模式建模¶

原文标题：AUTOSAR FlexRay Transceiver Operation Mode Model

The FlexRay Transceiver operation modes are described in the state diagram below.

The main idea behind this diagram is to support many currently available FlexRay Transceivers in a common model view. Depending on the transceiver device, the model may have one or two states more than necessary for a given device but this will clearly decouple the ComM and EcuM from the used hardware.

⌈ The FlexRay Transceiver Driver shall set each FlexRay Transceiver to SLEEP or STANDBY mode during the driver initialization, depending on the configuration of FrTrcvInitState. ⌋

State	Description
POWER_ON	ECU is fully powered.
NOT_ACTIVE	State of FlexRay transceiver hardware depends on ECU hardware and on SPAL driver configuration. FlexRay Transceiver Driver is not initialized and therefore not active.
ACTIVE	The function FrTrcv_Init() was called. This moves FlexRay Transceiver Driver to the active state selected by configuration.
NORMAL	Full bus communication is possible depending on ComM state. If FlexRay transceiver hardware controls ECU power supply, ECU is fully powered. The FlexRay Transceiver Driver detects no further wake up information.
STANDBY	No communication is possible.

21. FlexRay 收发器 hardware operation modes¶

原文标题：FlexRay transceiver hardware operation modes

The FlexRay transceiver hardware may support more mode transitions than shown in the state diagram above. The dependencies and the recommended implementation are explained in this chapter.

22. Temporary "Go-To-Sleep" 模式¶

原文标题：Temporary "Go-To-Sleep" Mode

The mode often referred to as "Go-to-sleep" is a temporary mode when switching from NORMAL to (optional) SLEEP. The FlexRay transceiver driver encapsulates such a temporary mode within one of the FlexRay transceiver driver software states. In addition, the FlexRay transceiver driver switches first from NORMAL to STANDBY and then with an additional (optional) API call from STANDBY to (optional) SLEEP.

The transition from NORMAL to STANDBY is not affected and will be performed directly.

⌈ The FlexRay transceiver driver encapsulates transient or temporary modes within one of the static optional or mandatory FlexRay transceiver driver software states. ⌋

23. "Active Star" 模式¶

原文标题："Active Star" Mode

⌈ If a transceiver supports active star mode, do NOT assume it is in node mode. ⌋

24. Enabling/Disabling 唤醒通知¶

原文标题：Enabling/Disabling wakeup notification

⌈ FrTrcv driver shall use the following APIs provided by ICU driver, to enable and disable the wakeup event notification:

Icu_EnableNotification
Icu_DisableNotification

FrTrcv driver shall enable/disable ICU channels only if reference is configured for the parameter FrTrcvIcuChannelRef. ⌋

FrTrcv driver shall ensure the following to avoid the loss of wakeup events:

⌈ It shall enable the ICU channels when the transceiver transitions to the Standby mode (FRTRCV_STANDBY). ⌋

⌈ It shall disable the ICU channels when the transceiver transitions to the Normal mode (FRTRCV_NORMAL). ⌋

25. 错误分类¶

原文标题：Error Classification

Chapter describes the error handling of the Basic Software in detail. Above all, it constitutes a classification scheme consisting of five error types which may occur in BSW modules.

Based on this foundation, the following section specifies particular errors arranged in the respective subsections below.

26. Development 错误¶

原文标题：Development Errors

Definition of development errors in module FrTrcv ⌈ | Type of error | Related error code | Error value | |---|---|---| | API service called with wrong parameter (FlexRay transceiver index out of range) | FRTRCV_E_FR_INVALID_TRCVIDX | 0x01 | | API service called with wrong parameter (FlexRay transceiver branch index out of range) | FRTRCV_E_FR_INVALID_BRANCHIDX | 0x02 | | API Service used without initialization | FRTRCV_E_UNINIT | 0x10 | | API service called passing a NULL pointer as a parameter | FRTRCV_E_PARAM_POINTER | 0x15 | | Invalid configuration set selection | FRTRCV_E_INIT_FAILED | 0x17 |

⌋

27. Runtime 错误¶

原文标题：Runtime Errors

Definition of runtime errors in module FrTrcv ⌈ | Type of error | Related error code | Error value | |---|---|---| | API service called in wrong transceiver operation mode | FRTRCV_E_FR_TRCV_NOT_STANDBY | 0x11 | | API service called in wrong transceiver operation mode | FRTRCV_E_FR_TRCV_NOT_NORMAL | 0x12 | | API service called in wrong transceiver operation mode | FRTRCV_E_FR_TRCV_NOT_SLEEP | 0x13 | | API service called in wrong transceiver operation mode | FRTRCV_E_FR_TRCV_NOT_RECEIVEONLY | 0x14 | | No/incorrect communication to transceiver | FRTRCV_E_FR_NO_CONTROL_TRCV | 0x16 |

⌋

28. Production 错误¶

原文标题：Production Errors

There are no production errors.

29. Extended Production 错误¶

原文标题：Extended Production Errors

30. FRTRCV_E_FR_ERRN_TRCV_¶

Error Status of Class A (GPIO) transceiver where is the transceiver index. Upstream requirements: ⌈ | Diagnostic Event (Error Name) | FRTRCV_E_FR_ERRN_TRCV_TrcvIdx | |---|---| | Description | Error Status of Class A general purpose input ouput port controlled transceiver where TrcvIdx is the transceiver index. | | Failed condition | ERRN pin is active low. | | Passed condition | ERRN pin is inactive high. |

⌋

31. FRTRCV_E_FR_BUSERROR_TRCV_¶

Error Status of Class B serial peripheral interface controlled transceiver. Upstream requirements: ⌈ | Diagnostic Event (Error Name) | FRTRCV_E_FR_BUSERROR_TRCV_TrcvIdx | |---|---| | Description | Error Status of Class B serial peripheral interface controlled transceiver where TrcvIdx is the transceiver index. | | Failed condition | Bus error, i.e. if any of bit 1...9 is set for transceivers according to class B of , see also . | | Passed condition | No Bus error, i.e. all of bit 1...9 are cleared for transceivers according to class B of , see also . |

⌋

Upstream requirements: ⌈ Production code errors and development errors of FlexRay Transceiver Driver are provided in the tables above. This list must be mapped into the code (i.e. the respective function calls to the error notifications must be in the code). ⌋

Note: The DEM module is configured to include these symbols, and the MCG of the DEM provides an header file with the symbols, which are then available to the FrTrcv module by inclusion of Dem.h.

Upstream requirements: ⌈ Error values naming convention

All AUTOSAR Basic Software Modules shall apply the following naming rules for all error values:

Error values shall have only CAPITAL LETTERS

32. 错误检测¶

原文标题：Error detection

Upstream requirements: ⌈ The FlexRay Transceiver Driver shall check the control communication to the transceiver and the reaction of the transceiver for correctness if supported by hardware. ⌋

⌈ In case of faults of the transceiver hardware, the FlexRay Transceiver Driver shall raise a runtime error FRTRCV_E_FR_NO_CONTROL_TRCV. ⌋

Example: Depending on the supported transceiver device, the driver could check the correctness of the executed control communication and the operation mode of the transceiver in order to detect defective or faulty transceiver hardware and/or corrupted SPI communication.

This check only applies to errors within the transceiver or the transceiver control communication (ports or SPI), i.e. errors caused by malfunction of the \muC, SW or a defect transceiver device.

⌈ The FrTrcv module shall check for bus errors and report them to DEM executing Dem_SetEventStatus(FRTRCV_E_FR_BUSERROR_TRCV_, DEM_EVENT_STATUS_PREFAILED). ⌋

⌈ If a no bus error is detected, the module shall execute Dem_SetEventStatus(FRTRCV_E_FR_BUSERROR_TRCV_, DEM_EVENT_STATUS_PREPASSED). ⌋

In the above descriptions, represents the transceiver index.

33. 错误通知¶

原文标题：Error notification

Upstream requirements: ⌈ If the configuration parameter FrTrcvErrorCheckDuringCommunication is set to true, the function FrTrcv_MainFunction shall report periodically the error state of the FlexRay transceiver to the Diagnostic Event Manager. ⌋

⌈ If an error (e.g. the state of the ERRN pin is active low) is detected the module shall execute Dem_SetEventStatus( FRTRCV_E_FR_ERRN_TRCV_, DEM_EVENT_STATUS_PREFAILED).

In the above description, represents the transceiver index. ⌋

⌈ If an error is not detected (e.g. the state of the ERRN pin is passive high) the module shall execute Dem_SetEventStatus( FRTRCV_E_FR_ERRN_TRCV_, DEM_EVENT_STATUS_PREPASSED).

In the above descriptions, represents the transceiver index. ⌋

Note: It is possible that ERRN status is active only for a short time. There is a possibility that ERRN status has already vanished when the MainFunction is executed. In this case, ERRN could be connected to an interrupt pin in the actual hardware. This way the transceiver driver would detect any active transitions of the ERRN status.

34. Preconditions for 驱动初始化¶

原文标题：Preconditions for driver initialization

⌈ The FrTrcv module shall use drivers for SPI and Dio to control the FlexRay bus transceiver hardware. ⌋

Note: The environment of the FrTrcv module ensures that all necessary BSW drivers (used by the FrTrcv module) have been initialized and are usable before FrTrcv_Init is called.

Thus, these drivers are assumed available and ready to operate before the FlexRay bus transceiver driver is initialized.

⌈ The FlexRay bus transceiver driver shall fulfill the FlexRay Transceiver hardware timing requirements also on initialization. ⌋

⌈ The FlexRay transceiver driver initialization shall schedule before other BSW modules (e.g. the FlexRay State manager) access its software services. ⌋

⌈ The runtime of the underlying services used shall be short enough and synchronous in order to fulfill the requirements defined by the and the timing requirements of the hardware device used. ⌋

⌈ The FlexRay Transceiver Driver runtime shall support setup and hold times of the FlexRay Transceiver Hardware devices in all states including low power states, e.g. sleep. ⌋

35. Instance concept¶

An ECU may contain multiple FlexRay transceivers. These transceivers can be of different types. Each transceiver type is handled by a dedicated FlexRay Transceiver Driver.

For your convenience, assume that any API call is not executed directly but is resolved by configuration to a zero based index into a function pointer table (per driver).

This issue is already resolved for Flexray Interface FrIf and the FlexRay communication controller.

Upstream requirements: ⌈ Multiple FlexRay transceivers of the same type are handled by a single FlexRay transceiver driver. ⌋

There is no need for multiple instances of this single FlexRay transceiver driver.

FrTrcv supports exactly one transceiver per CC and channel (i.e., it is not permitted that two CCs of one ECU share one FlexRay transceiver)!

36. Wake Up 支持¶

原文标题：Wake Up Support

From the EcuM point of view, the FrTrcv only needs to detect and report passive wakeups if supported by hardware. An active wakeup or power-on is handled by the EcuM/ComM anyway and there is no need to ask FrTrcv.

37. Power-on：¶

原文标题：Power-on:

EcuM is started and no wakeup source reports a passive wakeup. So EcuM does a full startup. Applications are started and if they request communication an active wakeup of the corresponding busses is performed by ComM.

38. Active 唤醒：¶

原文标题：Active wakeup:

EcuM wakes up and checks the wakeup sources. If it was a wakeup, the wakeup source reports the wakeup event. Since the wakeup source (here a port pin or similar) is not a communication network, EcuM will not inform ComM. Instead, applications are started and if they request communication a startup of the corresponding networks is performed by ComM.

39. Passive 唤醒：¶

原文标题：Passive wakeup:

EcuM wakes up and checks the wakeup sources. If it was a wakeup, the wakeup source reports the wakeup event. Since the wakeup source (this time bus transceivers and/or controllers) is a communication network, EcuM will inform ComM. ComM will perform a startup of this network.

So, EcuM only needs a wakeup event from FrTrcv in case of a passive wakeup. Allother cases shall not be reported to EcuM.

40. 版本检查¶

原文标题：Version checking

For details refer to .

41. 安全事件¶

原文标题：Security Events

The module does not report security events.

42. API 规范¶

原文标题：API specification

43. Imported 类型¶

原文标题：Imported types

In this chapter all types included from the following files are listed.

Definition of imported datatypes of module FrTrcv ⌈ | Module | Header File | Imported Type | |---|---|---| | Dem | Rte_Dem_Type.h | Dem_EventIdType | | ^ | Rte_Dem_Type.h | Dem_EventStatusType | | Dio | Dio.h | Dio_ChannelGroupType | | ^ | Dio.h | Dio_ChannelType | | ^ | Dio.h | Dio_LevelType | | ^ | Dio.h | Dio_PortLevelType | | ^ | Dio.h | Dio_PortType | | EcuM | EcuM.h | EcuM_WakeupSourceType | | Icu | Icu.h | Icu_ChannelType | | Spi | Spi.h | Spi_ChannelType | | ^ | Spi.h | Spi_DataBufferType | | ^ | Spi.h | Spi_NumberOfDataType | | ^ | Spi.h | Spi_SequenceType | | ^ | Spi.h | Spi_StatusType | | Std | Std_Types.h | Std_ReturnType |

⌋

44. 类型定义¶

原文标题：Type definitions

Separation of error and status values Upstream requirements: ⌈ All Basic Software Modules shall strictly separate error and status information. This requirement applies to return values and also to internal variables. ⌋

Do not return development error codes via API Upstream requirements: ⌈ All AUTOSAR Basic Software Modules shall not return specific development error codes via the API. In case of a detected development error the error shall only be reported to the DET. If the API- function which detected the error has a return type it shall return E_NOT_OK. ⌋

Module specific API return types Upstream requirements: ⌈ If a Basic Software Module needs module specific return types, it shall use one of the following possibilities:

Use uint8 as return value, take the standard E_OK value from Std_Types.h and define additional return values using #define.
Define a module specific return value with typedef enum.

Hint: Within this enum, E_OK cannot be used (because E_OK is already #defined in Std_Types.h and OSEK OS) ⌋

45. FrTrcv_ConfigType¶

Definition of datatype FrTrcv_ConfigType Upstream requirements: ⌈ | Name | FrTrcv_ConfigType | < | |---|---|---| | Kind | Structure | < | | Elements | implementation specific | < | | ^ | Type | - | | ^ | Comment | - | | Description | Configuration data structure of the FrTrcv module. | < | | Available via | FrTrcv.h | < |

⌋

46. FrTrcv_TrcvModeType¶

Definition of datatype FrTrcv_TrcvModeType ⌈ | Name | FrTrcv_TrcvModeType | < | < | |---|---|---|---| | Kind | Enumeration | < | < | | Range | FRTRCV_TRCVMODE_NORMAL | - | Transceiver is in state NORMAL | | ^ | FRTRCV_TRCVMODE_STANDBY | - | Transceiver is in state STANDBY | | ^ | FRTRCV_TRCVMODE_SLEEP | - | Transceiver is in state SLEEP | | ^ | FRTRCV_TRCVMODE_RECEIVEONLY | - | Transceiver is in state RECEIVEONLY | | Description | Transceiver modes in state ACTIVE. | < | < | | Available via | Fr_GeneralTypes.h | < | < |

⌋

Status values naming convention Upstream requirements: ⌈ The following naming rules apply for status values that are visible outside of the module: - Status values shall have only CAPITAL LETTERS - Naming convention: FRTRCV_

If consists of several words, they shall be separated by underscores. ⌋

⌈ The type definition FrTrcv_TrcvModeType shall be protected by a FR_GENERAL_TYPES define in order:

to be shared between different FlexRay Transceiver Drivers
to be included into the FrIf

If different FlexRay Transceiver Drivers are used, only one instance of this file has to be included in the source tree ⌋

According to , at least these operation modes are defined:

47. FrTrcv_TrcvWUReasonType¶

⌈ The type definition FrTrcv_TrcvWUReasonType shall be protected by a FR_GENERAL_TYPES define in order:

to be shared between different FlexRay Transceiver Drivers
to be included into the FrIf

If different FlexRay Transceiver Drivers are used, only one instance of this file has to be included in the source tree. ⌋

Definition of datatype FrTrcv_TrcvWUReasonType Upstream requirements: ⌈ | Name | FrTrcv_TrcvWUReasonType | < | < | |---|---|---|---| | Kind | Enumeration | < | < | | Range | FRTRCV_WU_NOT_SUPPORTED | - | The transceiver does not support any information for the wake up reason. | | ^ | FRTRCV_WU_BY_BUS | - | The transceiver has detected that the bus has caused the wake up of the ECU. | | ^ | FRTRCV_WU_BY_PIN | - | The transceiver has detected a wake-up event at one of the transceiver's pins (not at the FlexRay bus). | | ^ | FRTRCV_WU_INTERNALLY | - | The transceiver has detected that the bus has woken up by the ECU via FrTrcv_SetTransceiverMode() API call | | ^ | FRTRCV_WU_RESET | - | The transceiver has detected that the "wake up" is due to an ECU reset. | | ^ | FRTRCV_WU_POWER_ON | - | The transceiver has detected that the "wake up" is due to an ECU reset after power on. |

其余 58 章（内容从略，见纯文本全文）¶

功能定义
FrTrcv_Init
FrTrcv_SetTransceiverMode
FrTrcv_GetTransceiverMode
FrTrcv_GetTransceiverWUReason
FrTrcv_ClearTransceiverWakeup
FrTrcv_CheckWakeupByTransceiver
FrTrcv_GetTransceiverError
FrTrcv_DisableTransceiverBranch
FrTrcv_EnableTransceiverBranch
Callback 通知
Scheduled functions
FrTrcv_MainFunction
Expected 接口
Mandatory 接口
Optional 接口
Configurable 接口
服务接口
时序图
配置规范
How to read this chapter
Containers and 配置 parameters
通用配置需求
FrTrcv
FrTrcvGeneral
FrTrcvChannel
FrTrcvChannelDemEventParameterRefs
FrTrcvBranchIdContainer
FrTrcvAccess
FrTrcvDioAccess
FrTrcvDioChannelAccess
FrTrcvSpiSequence
发布信息
附录
Change history of AUTOSAR traceable items
Traceable item history of this document according to AUTOSAR Release R26-11
Added 规范 Items in R26-11
Changed 规范 Items in R26-11
Deleted 规范 Items in R26-11
Traceable item history of this document according to AUTOSAR Release R25-11
Added 规范 Items in R25-11
Changed 规范 Items in R25-11
Deleted 规范 Items in R25-11
Traceable item history of this document according to AUTOSAR Release R24-11
Added 规范 Items in R24-11
Changed 规范 Items in R24-11
Deleted 规范 Items in R24-11
Traceable item history of this document according to AUTOSAR Release R23-11
Added 规范 Items in R23-11
Changed 规范 Items in R23-11
Deleted 规范 Items in R23-11
Traceable item history of this document according to AUTOSAR Release R22-11
Added 规范 Items in R22-11
Changed 规范 Items in R22-11
Deleted 规范 Items in R22-11
Added Constraints in R22-11
Changed Constraints in R22-11
Deleted Constraints in R22-11

Specification of FlexRay Transceiver Driver (FlexRayTransceiverDriver)¶