Specification of FlexRay Driver (`FlexRayDriver`)¶

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

本地文件¶

规范 PDF: F:\Work\Standards\01_Sources\CP_SWS_FlexRayDriver_026\AUTOSAR_CP_SWS_FlexRayDriver.pdf
ARXML 模型: F:\Work\Standards\01_Sources\CP_SWS_FlexRayDriver_026\AUTOSAR_CP_SWS_FlexRayDriver.arxml
纯文本全文: F:\Work\Standards\01_Sources\CP_SWS_FlexRayDriver_026\zzgen\CP_SWS_FlexRayDriver.complete.txt

文档简介¶

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

The FlexRay Driver abstracts the hardware related implementation details of specific FlexRay Communication Controllers (CC). This specification basically relies on FlexRay CCs compliant to the FlexRay specification . Additionally older FlexRay controllers compliant to FlexRay specification are supported by this specification. Different behaviours in this SWS resulting from the different supported FlexRay specifications are pointed out as footnotes or remarks where applicable.

All supported features of a FlexRay controller are encapsulated within the Fr module and shall be accessed via this uniform interface only. The APIs provide abstract functional operations that are mapped to a sequence of hardware accesses depending on the actual implemented Fr module. Thus, the FlexRay Interface (FrIf), as the user of the Fr module, is independent of the underlying FlexRay CC hardware. The Fr module doesn't have a main-function or an ISR. All Fr module API functions are executed only in the context of the FrIf.

A single Fr module supports only a single type of FlexRay CC hardware implementation. The Fr supports multiple FlexRay CCs of this single hardware implementation. The FlexRay Driver's prefix is uniquely assigned per Fr module to allow usage of different FlexRay Drivers, the names of which are separated by namespace. The FrIf can access different FlexRay CC hardware implementations using different FlexRay Drivers. The FrIf configuration determines which driver from among different types is used to access a particular CC.

The configuration of the Fr module shall be done at system configuration time, with the Fr module's specific configuration being generated by a Module Configuration Generator (MCG), which translates the parameters out of the ECU configuration parameters to Fr module specific configuration data structures.

depicts the basic structure of the FlexRay stack. One FrIf accesses several CCs using one or several FlexRay Drivers.

模块依赖¶

This chapter lists the modules interacting with the Fr module.

Modules that use Fr module:

The FrIf is the only user of the Fr module (except initialization by EcuM). It uses the Fr module(s) to access possibly different FlexRay Communication Controllers in a uniform and abstract way.
The EcuM initializes the Fr module by calling Fr_Init.

Modules used by the Fr module:

* ⌈ The Fr module shall use the BSW Scheduler mechanisms for data consistency when required. ⌋

Other Module dependencies:

* ⌈ On certain systems the CC might share resources with other components (e.g., the MCU), and might depend on their configurations. If those resources are within the scope of the other modules (e.g., PLL configuration, memory mapping), then the Fr module doesn't configure those components but requires that their initialization precede the Fr module's initialization. ⌋

章节详细内容¶

1. 简介与功能概述¶

原文标题：Introduction and functional overview

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

The FlexRay Driver abstracts the hardware related implementation details of specific FlexRay Communication Controllers (CC). This specification basically relies on FlexRay CCs compliant to the FlexRay specification . Additionally older FlexRay controllers compliant to FlexRay specification are supported by this specification. Different behaviours in this SWS resulting from the different supported FlexRay specifications are pointed out as footnotes or remarks where applicable.

All supported features of a FlexRay controller are encapsulated within the Fr module and shall be accessed via this uniform interface only. The APIs provide abstract functional operations that are mapped to a sequence of hardware accesses depending on the actual implemented Fr module. Thus, the FlexRay Interface (FrIf), as the user of the Fr module, is independent of the underlying FlexRay CC hardware. The Fr module doesn't have a main-function or an ISR. All Fr module API functions are executed only in the context of the FrIf.

2. 缩略语¶

原文标题：Acronyms and Abbreviations

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

Abbreviation / Acronym:	Description:
API	Application Programming Interface
AUTOSAR	Automotove Open Systems Architecture
BSW	Basic Software
DEM/Dem	Autosar Module: Diagnostic Event Manager
DET/Det	Autosar Module: Default Error Tracer
ECU	Electronic Control Unit
MCG	Module Configuration Generator
CC	Communication Controller
CHI	Controller Host Interface
FIFO	First In First Out buffer
Fr	Autosar Module: FlexRay Driver
FrIf	Autosar Module: FlexRay Interface
FrTp	Autosar Module: FlexRay Transport Protocol
FrTrcv	Autosar Module: FlexRay Transceiver Driver
ID/Id	Identifier
ISR	Interrupt Service Routine
LPdu	Datalink layer Protocol Datagram Unit
MCAL	Microcontroller Abstraction Layer
MCU	Microcontroller Unit
MISRA	Motor Industry Software Reliability Association
NIT	FlexRay Network Idle Time
n/a	Not Applicable
OS	Operating System
PLL	Phase Locked Loop
POC	Protocol Operation Control (see for details)
POCState	Actual CC internal state of the POC.

3. 相关文档¶

原文标题：Related documentation

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

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

5. 相关规范¶

原文标题：Related specification

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

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

6. 约束与假设¶

原文标题：Constraints and assumptions

7. 限制¶

原文标题：Limitations

⌈ In the dynamic segment of each FlexRay Communication Cycle, a transmit/receive buffer of a FlexRay Communication Controller shall be used only one particular LPdu. This limits the reconfiguration possibilities and thus restricts the number of transmittable (sent and received) LPdus per dynamic segment to the accumulated number (over all CCs on one ECU) of transmit/receive buffers connected to one cluster. This limitation results from the unpredictability of the time of transmission of an LPdu within the dynamic segment. Because of that a point in time for the reconfiguration of a certain buffer for multiple usages within the dynamic segment cannot be predetermined. ⌋

8. 适用的车型领域¶

原文标题：Applicability to car domains

The FlexRay Communication stack can be used wherever high data rates and fault tolerant communication (in conjunction with ) are required. Furthermore it enables the synchronized operation of several ECUs within a car.

9. 对其他模块的依赖¶

原文标题：Dependencies to other modules

This chapter lists the modules interacting with the Fr module.

Modules that use Fr module:

The FrIf is the only user of the Fr module (except initialization by EcuM). It uses the Fr module(s) to access possibly different FlexRay Communication Controllers in a uniform and abstract way.
The EcuM initializes the Fr module by calling Fr_Init.

Modules used by the Fr module:

* ⌈ The Fr module shall use the BSW Scheduler mechanisms for data consistency when required. ⌋

Other Module dependencies:

* ⌈ On certain systems the CC might share resources with other components (e.g., the MCU), and might depend on their configurations. If those resources are within the scope of the other modules (e.g., PLL configuration, memory mapping), then the Fr module doesn't configure those components but requires that their initialization precede the Fr module's initialization. ⌋

10. 文件结构¶

原文标题：File structure

This section gives an overview about the files and their relations required for a proper implementation of the Fr module. Please note that the file structure is not completely specified but the implementation shall use at least the files and the file structure presented in this section.

11. 代码文件结构¶

原文标题：Code file structure

Upstream requirements: , ⌈ The code file structure shall not be completely defined within this specification. ⌋

12. 头文件结构¶

原文标题：Header file structure

⌈ The file Fr.h shall contain all types and function prototypes required by the Fr module's environment. ⌋

⌈ Fr_GeneralTypes.h shall contain all types and constants that are shared among the AUTOSAR FlexRay modules Fr, FrIf and FrTrcv. ⌋

13. 需求追踪¶

原文标题：Requirements Tracing

Requirement	Description	Satisfied by
All software modules shall provide version and identification information
Data types naming convention
Global variables naming convention
AUTOSAR Basic Software Modules shall not define global data in their header files, but in the C file
Machine readable module description
Basic SW module shall be able to shutdown
It shall be possible to create an AUTOSAR ECU out of modules provided as source code and modules provided as object code, even mixed
BSW Modules shall support pre-compile configuration
All AUTOSAR Basic Software Modules shall provide at least a basic set of module files
A Naming seperation of different instances of BSW drivers shall be in place
All AUTOSAR standard types and constants shall be placed and organized in a standard type header file
All type definitions of target and compiler specific scope shall be placed and organized in a single type header
The return type of init() functions implemented by AUTOSAR Basic Software Modules shall be void
All Basic Software Modules shall provide a readable module vendor identification
All software modules shall pro

14. 功能规范¶

原文标题：Functional specification

15. 总体描述¶

原文标题：General description

Upstream requirements: ⌈ A single Fr module offers a uniform way to use features of FlexRay CCs independent of the CC implementation, thus hiding the actual hardware implementation (registers, buffers, etc.) from upper layers. ⌋

Upstream requirements: ⌈ The Fr module maps abstract functional requests to sequences of CC specific hardware accesses. ⌋

A detailed description for all API services can be found in .

16. Implementation 需求¶

原文标题：Implementation Requirements

This chapter lists requirements that shall be fulfilled by Fr module implementations.

Upstream requirements: ⌈ The Fr module's implementer shall replace all prefixes Fr within the Fr specification by a vendor specific prefix Fr__ during implementation to allow the usage of different FlexRay Drivers within one build system. The Fr module's implementer shall apply this rule to all prefixes within filenames, Fr module specific datatypes, Fr module specific constants, Fr module specific global variables and API functions. ⌋

Upstream requirements: ⌈ The Fr module shall implement the API functions specified by the Fr SWS as real C-code functions and shall not implement the API functions as macros. ⌋

⌈ The rationale of is to allow object code module integration. ⌋

Upstream requirements: ⌈ None of the Fr module's header files shall define global variables. ⌋

Upstream requirements: ⌈ The Fr module or the underlying hardware or both shall stop FlexRay timers in case of loss of synchronization. ⌋

The implementation may assume that

17. Indexing Scheme¶

Users of the Fr identify Fr resources by using an indexing scheme as depicted in .

The following Fr resources are available:

Upstream requirements: ⌈ CCs are identified via controller indices (Fr_CtrlIdx). ⌋

Upstream requirements: ⌈ Each driver's CCs are identified by controller indices 0 to (n-1) where n is the number of CCs controlled by the particular Fr. ⌋

⌈ For each FlexRay CC the connected channels are identified by channel indices (Fr_ChnlIdx). ⌋

⌈ A dedicated type that holds the enumerations FR_CHANNEL_A, FR_CHANNEL_B or FR_CHANNEL_AB represents the channel index. ⌋

⌈ Channel indices are only valid within a tuple <Fr_CtrlIdx, Fr_ChnlIdx>. ⌋

Upstream requirements: , ⌈ Each FlexRay frame processed by Fr API functions is identified by an LPdu index (Fr_LPduIdx). ⌋

⌈ Each LPdu carries the LSdu. Each controller's LPdus are identified by LPdu indices from 0 to (n-1) where n is the number of LPdus processed by the corresponding CC. ⌋

⌈ LPdu indices are only valid within a tuple <Fr_CtrlIdx, Fr_LPduIdx>. ⌋

⌈ An Fr_LPduIdx uniquely identifies the following parameters of a FlexRay frame as a key: {Slot ID, Channel, cycle repetition, base cycle, transmit/receive}. ⌋

18. POC 状态 machine 控制¶

原文标题：POC state machine control

⌈ Since a FlexRay CC is condition-based, it internally maintains a state machine, the Protocol Operation Control (POC) state machine. The state transitions are driven both by hardware related events as well as by commands passed by the host at the CHI (see for details). ⌋

⌈ The CHI commands driving the POC state machine are incorporated into several Fr module API functions. API functions affecting the POC state of a FlexRay CC are:

Fr_StartCommunication()
Fr_HaltCommunication()
Fr_AbortCommunication()
Fr_SendWUP()
Fr_ControllerInit() ⌋

⌈ All API functions other than those listed above shall not change the POC state of the FlexRay CC. Figure 3 shows the POC states of the FlexRay CC and the transitions applicable to the Fr module API functions. Note that

certain transitions (marked with *)) are performed by the invocation of a single API function call (Fr_ControllerInit()).
certain transitions might be implicitly performed by the FlexRay CC without external command invocation (dotted arrow)
certain transitions specified cannot be performed by the current Fr module API (not drawn in Figure 3 - compare to ). ⌋

19. FIFO 支持 and message ID 过滤¶

原文标题：FIFO support and message ID filtering

To efficiently support reception in certain use-cases, FlexRay controllers might support receive-FIFOs. The receive-FIFOs accept FlexRay frames based on a set of configured filter criterias which match FlexRay specific properties such as frameID, cycle, channel, as well as protocol add-ons like the message ID, in hardware.

Upstream requirements: , ⌈ The hardware receive-FIFO shall be used if the FIFO filter-criterias as configured can be applied to the hardware FIFO. ⌋

Upstream requirements: ⌈ All LPdus (as configured within FrIf) matching a receive-FIFO's filter-criteria shall be assigned to the respective receive-FIFO. ⌋

Upstream requirements: ⌈ No specific buffers shall be assigned to LPdus that are assigned to a receive-FIFO. ⌋

Upstream requirements: ⌈ If Fr_ReceiveRxLPdu() is called for an LPdu assigned to the receive FIFO, the service Fr_ReceiveRxPdu() consumes the first valid frame out of the respective FIFO and returns it as received frame. There is no receive-FIFO specific API, thus keeping the upper layers unaffected. ⌋

Hint: This restricted implementation of the receive-FIFO covers a very typical use-case (FrTp):

20. 配置描述¶

原文标题：Configuration description

Upstream requirements: , , , ⌈ The Fr module shall provide an XML file that contains the data, which is required for the SW identification and configuration parameters. This file shall describe vendor specific configuration parameters if applicable. ⌋

Upstream requirements: ⌈ A driver MCG reads the ECU configuration parameters of the Fr and the FrIf modules. While cluster related configuration parameters are contained in the FrIf module's configuration, CC related configuration parameters are contained in the Fr module's configuration. The Fr module's specific configuration tool shall read both ECU module configurations to derive the configuration parameters for all FlexRay CCs mapped to the Fr module. ⌋

⌈ All frame transmission/reception related configuration parameters are located only in the FrIf module description (within configuration containers 'FrIfLPdu' and 'FrIfFrameTriggering'). The Fr must be able to handle all transmission/reception requests of all related LPdus.

21. 错误分类¶

原文标题：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.

22. Development 错误¶

原文标题：Development Errors

Definition of development errors in module Fr ⌈ | Type of error | Related error code | Error value | |---|---|---| | parameter timer index exceeds number of available timers | FR_E_INV_TIMER_IDX | 0x01 | | invalid pointer in parameter list | FR_E_PARAM_POINTER | 0x02 | | parameter offset exceeds bounds | FR_E_INV_OFFSET | 0x03 | | invalid controller index | FR_E_INV_CTRL_IDX | 0x04 | | invalid channel index | FR_E_INV_CHNL_IDX | 0x05 | | parameter cycle exceeds 63 | FR_E_INV_CYCLE | 0x06 | | Fr module was not initialized | FR_E_INIT_FAILED | 0x08 | | Payload length parameter has an invalid value | FR_E_INV_LENGTH | 0x0A | | invalid LPdu index | FR_E_INV_LPDU_IDX | 0x0B | | invalid FlexRay header CRC | FR_E_INV_HEADERCRC | 0x0C | | invalid value passed as parameter Fr_ConfigParamIdx | FR_E_INV_CONFIG_IDX | 0x0D | | invalid framelist size value | FR_E_INV_FRAMELIST_SIZE | 0x0E |

⌋

23. Runtime 错误¶

原文标题：Runtime Errors

Definition of runtime errors in module Fr ⌈ | Type of error | Related error code | Error value | |---|---|---| | Fr CC is not in the expected POC state | FR_E_INV_POCSTATE | 0x09 |

⌋

24. Production 错误¶

原文标题：Production Errors

There are no production errors.

25. Extended Production 错误¶

原文标题：Extended Production Errors

⌈ | Error Name: | FR_E_CTRL_TESTRESULT | < | |---|---|---| | Short Description: | FlexRay Controller hardware error | < | | Long Description: | This extended production error indicates hardware errors of the FlexRay communication controller. Please note that this extended production error does not address Flexray protocol errors detected on the network. | < | | Detection Criteria: | Fail | Every API function accessing hardware registers of the FlexRay controller might detect a missbehavior of the device compared to the device specification. |

For details see requirements: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , | ^ | Pass | During FlexRay communication controller initialization (function Fr_ControllerInit()) the proper operation of the hardware registers is successfully verified. | |---|---|---|

For details see requirements: | Secondary Parameters: | In case of successful device operation verification (function Fr_ControllerInit()) report PASS. | |---|---|

In case of an error always report FAIL.	<
Time Required:	If a FlexRay Controller hardware error occurs it shall be immediately reported as error.	<
Monitor Frequency:	continuous	<

⌋

26. 安全事件¶

原文标题：Security Events

The module does not report security events.

27. API 规范¶

原文标题：API specification

Upstream requirements: ⌈ All API functions or global variables, whether they are specified or not shall follow the naming scheme Fr_, where the first letter of each word in is written uppercase and the remainder of the word lowercase. ⌋

28. Imported 类型¶

原文标题：Imported types

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

Definition of imported datatypes of module Fr Upstream requirements: , ⌈ | Module | Header File | Imported Type | |---|---|---| | Dem | Rte_Dem_Type.h | Dem_EventIdType | | ^ | Rte_Dem_Type.h | Dem_EventStatusType | | Std | Std_Types.h | Std_ReturnType | | ^ | Std_Types.h | Std_VersionInfoType |

⌋

29. Macro 定义¶

原文标题：Macro definitions

30. 配置 parameter index macros¶

原文标题：Configuration parameter index macros

The following table lists macros which list symbolic names that can be passed into API function Fr_ReadCCConfig() as parameter Fr_ConfigParamIdx (see ).

Each macro (index) uniquely identifies a configuration parameter which value can be read out of the controller's configuration using Fr_ReadCCConfig().

Macro name:	Value:	Mapps to configuration parameter:
FR_CIDX_GDCYCLE	0	FrIfGdCycle
FR_CIDX_PMICROPERCYCLE	1	FrPMicroPerCycle
FR_CIDX_PDLISTENTIMEOUT	2	FrPdListenTimeout
FR_CIDX_GMACROPERCYCLE	3	FrIfGMacroPerCycle
FR_CIDX_GDMACROTICK	4	FrIfGdMacrotick
FR_CIDX_GNUMBEROFMINISLOTS	5	FrIfGNumberOfMinislots
FR_CIDX_GNUMBEROFSTATICSLOTS	6	FrIfGNumberOfStaticSlots
FR_CIDX_GDNIT	7	FrIfGdNit
FR_CIDX_GDSTATICSLOT	8	FrIfGdStaticSlot
FR_CIDX_GDWAKEUPRXWINDOW	9	FrIfGdWakeupRxWindow
FR_CIDX_PKEYSLOTID	10	FrPKeySlotId
FR_CIDX_PLATESTTX	11	FrPLatestTx
FR_CIDX_POFFSETCORRECTIONOUT	12	FrPOffsetCorrectionOut
FR_CIDX_POFFSETCORRECTIONSTART	13	FrPOffsetCorrectionStart
FR_CIDX_PRATECORRECTIONOUT	14	FrPRateCorrectionOut
FR_CIDX_PSECONDKEYSLOTID	15	FrPSecondKeySlotId
FR_CIDX_PDACCEPTEDSTARTUPRANGE	16	FrPdAcceptedStartupRange

FR_CIDX_G

31. 类型定义¶

原文标题：Type definitions

⌈ The content of Fr_GeneralTypes.h shall be protected by a FR_GENERAL_TYPES define. ⌋

⌈ If different FlexRay drivers are used, only one instance of this file has to be included in the source tree. For implementation all Fr_GeneralTypes.h related types in the documents mentioned before shall be considered. ⌋

Upstream requirements: ⌈ All types whether they are specified or implementation dependant shall follow the naming scheme Fr_Type, where the first letter of each word in is written uppercase and the remainder of the word is written lowercase. ⌋

32. Fr_ConfigType¶

Definition of datatype Fr_ConfigType ⌈ | Name | Fr_ConfigType | < | |---|---|---| | Kind | Structure | < | | Description | This type contains the implementation-specific post build configuration structure. | < | | Available via | Fr.h | < |

⌋

⌈ Rules of shall be applied to Fr_ConfigType. ⌋

33. Fr_POCStateType¶

Definition of datatype Fr_POCStateType Upstream requirements: ⌈ | Name | Fr_POCStateType | < | < | |---|---|---|---| | Kind | Enumeration | < | < | | Range | FR_POCSTATE_CONFIG | 0x00 | Represents literal CONFIG of formal type definition T_POCState. | | ^ | FR_POCSTATE_DEFAULT_CONFIG | 0x01 | Represents literal DEFAULT_CONFIG of formal type definition T_POCState. | | ^ | FR_POCSTATE_HALT | 0x02 | Represents literal HALT of formal type definition T_POCState. | | ^ | FR_POCSTATE_NORMAL_ACTIVE | 0x03 | Represents literal NORMAL_ACTIVE of formal type definition T_POCState. | | ^ | FR_POCSTATE_NORMAL_PASSIVE | 0x04 | Represents literal NORMAL_PASSIVE of formal type definition T_POCState. | | ^ | FR_POCSTATE_READY | 0x05 | Represents literal READY of formal type definition T_POCState. | | ^ | FR_POCSTATE_STARTUP | 0x06 | Represents literal STARTUP of formal type definition T_POCState. | | ^ | FR_POCSTATE_WAKEUP | 0x07 | Represents literal WAKEUP of formal type definition T_POCState. | | Description | This formal definition refers to the description of type T_POCState in chapter 2.2.1.3 POC status of . | < | < | | Available via | Fr_GeneralTypes.h | < | < |

⌋

34. Fr_SlotModeType¶

Definition of datatype Fr_SlotModeType Upstream requirements: ⌈ | Name | Fr_SlotModeType | < | < | |---|---|---|---| | Kind | Enumeration | < | < | | Range | FR_SLOTMODE_KEYSLOT | 0x00 | Represents literal KEYSLOT of formal type definition T_SlotMode. | | ^ | FR_SLOTMODE_ALL_PENDING | 0x01 | Represents literal ALL_PENDING of formal type definition T_SlotMode. | | ^ | FR_SLOTMODE_ALL | 0x02 | Represents literal ALL of formal type definition T_SlotMode. | | Description | This formal definition refers to the description of type T_SlotMode in chapter 2.2.1.3 POC status of . | < | < | | Available via | Fr_GeneralTypes.h | < | < |

⌋

.]

35. Fr_ErrorModeType¶

Definition of datatype Fr_ErrorModeType Upstream requirements: ⌈ | Name | Fr_ErrorModeType | < | < | |---|---|---|---| | Kind | Enumeration | < | < | | Range | FR_ERRORMODE_ACTIVE | 0x00 | Represents literal ACTIVE of formal type definition T_ErrorMode. | | ^ | FR_ERRORMODE_PASSIVE | 0x01 | Represents literal PASSIVE of formal type definition T_ErrorMode. | | ^ | FR_ERRORMODE_COMM_HALT | 0x02 | Represents literal COMM_HALT of formal type definition T_ErrorMode. | | Description | This formal definition refers to the description of type T_ErrorMode in chapter 2.2.1.3 POC status of . | < | < | | Available via | Fr_GeneralTypes.h | < | < |

⌋

36. Fr_WakeupStatusType¶

Definition of datatype Fr_WakeupStatusType Upstream requirements: ⌈ | Name | Fr_WakeupStatusType | < | < | |---|---|---|---| | Kind | Enumeration | < | < | | Range | FR_WAKEUP_UNDEFINED | 0x00 | Represents literal UNDEFINED of formal type definition T_WakeupStatus. | | ^ | FR_WAKEUP_RECEIVED_HEADER | 0x01 | Represents literal RECEIVED_HEADER of formal type definition T_WakeupStatus. | | ^ | FR_WAKEUP_RECEIVED_WUP | 0x02 | Represents literal RECEIVED_WUP of formal type definition T_WakeupStatus. | | ^ | FR_WAKEUP_COLLISION_HEADER | 0x03 | Represents literal COLLISION_HEADER of formal type definition T_WakeupStatus. | | ^ | FR_WAKEUP_COLLISION_WUP | 0x04 | Represents literal COLLISION_WUP of formal type definition T_WakeupStatus. | | ^ | FR_WAKEUP_COLLISION_UNKNOWN | 0x05 | Represents literal COLLISION_UNKNOWN of formal type definition T_WakeupStatus. | | ^ | FR_WAKEUP_TRANSMITTED | 0x06 | Represents literal TRANSMITTED of formal type definition T_WakeupStatus. | | Description | This formal definition refers to the description of type T_WakeupStatus in chapter 2.2.1.3 POC status of . | < | < | | Available via | Fr_GeneralTypes.h | < | < |

⌋

37. Fr_StartupStateType¶

Definition of datatype Fr_StartupStateType Upstream requirements: ⌈ | Name | Fr_StartupStateType | < | < | |---|---|---|---| | Kind | Enumeration | < | < | | Range | FR_STARTUP_UNDEFINED | 0x00 | Represents literal UNDEFINED of formal type definition T_StartupState. | | ^ | FR_STARTUP_COLDSTART_LISTEN | 0x01 | Represents literal COLDSTART_LISTEN of formal type definition T_StartupState. | | ^ | FR_STARTUP_INTEGRATION_COLDSTART_CHECK | 0x02 | Represents literal INTEGRATION_COLDSTART_CHECK of formal type definition T_StartupState. | | ^ | FR_STARTUP_COLDSTART_JOIN | 0x03 | Represents literal COLDSTART_JOIN of formal type definition T_StartupState. | | ^ | FR_STARTUP_COLDSTART_COLLISION_RESOLUTION | 0x04 | Represents literal COLDSTART_COLLISION_RESOLUTION of formal type definition T_StartupState. | | ^ | FR_STARTUP_COLDSTART_CONSISTENCY_CHECK | 0x05 | Represents literal COLDSTART_CONSISTENCY_CHECK of formal type definition T_StartupState. | | ^ | FR_STARTUP_INTEGRATION_LISTEN | 0x06 | Represents literal INTEGRATION_LISTEN of formal type definition T_StartupState. | | ^ | FR_STARTUP_INITIALIZE_SCHEDULE | 0x07 | Represents literal INITIALIZE_SCHEDULE of formal type definition T_StartupState. |

38. Fr_POCStatusType¶

Definition of datatype Fr_POCStatusType ⌈ | Name | Fr_POCStatusType | < | |---|---|---| | Kind | Structure | < | | Elements | CHIHaltRequest | < | | ^ | Type | boolean | | ^ | Comment | - | | ^ | ColdstartNoise | < | | ^ | Type | boolean | | ^ | Comment | - | | ^ | ErrorMode | < | | ^ | Type | Fr_ErrorModeType | | ^ | Comment | - | | ^ | Freeze | < | | ^ | Type | boolean | | ^ | Comment | - | | ^ | SlotMode | < | | ^ | Type | Fr_SlotModeType | | ^ | Comment | - | | ^ | StartupState | < | | ^ | Type | Fr_StartupStateType | | ^ | Comment | - | | ^ | State | < | | ^ | Type | Fr_POCStateType | | ^ | Comment | - | | ^ | WakeupStatus | < | | ^ | Type | Fr_WakeupStatusType | | ^ | Comment | - | | ^ | CHIReadyRequest | < | | ^ | Type | boolean | | ^ | Comment | - | | Description | This formal definition refers to the description of type T_POCStatus in chapter 2.2.1.3 POC status of . | < | | Available via | Fr_GeneralTypes.h | < |

⌋

39. Fr_TxLPduStatusType¶

Definition of datatype Fr_TxLPduStatusType Upstream requirements: ⌈ | Name | Fr_TxLPduStatusType | < | < | |---|---|---|---| | Kind | Enumeration | < | < | | Range | FR_TRANSMITTED | 0x00 | LPdu has been transmitted | | ^ | FR_TRANSMITTED_CONFLICT | 0x01 | A transmission conflict has occurred. | | ^ | FR_NOT_TRANSMITTED | 0x02 | LPdu has not been transmitted | | Description | These values are used to determine whether a LPdu has been transmitted or not. | < | < | | Available via | Fr_GeneralTypes.h | < | < |

⌋

40. Fr_RxLPduStatusType¶

Definition of datatype Fr_RxLPduStatusType Upstream requirements: ⌈ | Name | Fr_RxLPduStatusType | < | < | |---|---|---|---| | Kind | Enumeration | < | < | | Range | FR_RECEIVED | 0x00 | LPdu has been received | | ^ | FR_NOT_RECEIVED | 0x01 | LPdu has not been received | | ^ | FR_RECEIVED_MORE_DATA_AVAILABLE | 0x02 | LPdu has been received. More instances of this LPdu are available (FIFO usage). | | Description | These values are used to determine if a LPdu has been received or not. | < | < | | Available via | Fr_GeneralTypes.h | < | < |

⌋

41. Fr_ChannelType¶

Definition of ImplementationDataType Fr_ChannelType Upstream requirements: ⌈ | Name | Fr_ChannelType | < | < | |---|---|---|---| | Kind | Enumeration | < | < | | Range | FR_CHANNEL_A | 0x01 | Refers to channel A of a CC. | | ^ | FR_CHANNEL_B | 0x02 | Refers to channel B of a CC. | | ^ | FR_CHANNEL_AB | 0x03 | Refers to both channels (A and B) of a CC. | | Description | The values are used to reference channels on a CC. | < | < | | Variation | - | < | < | | Available via | Fr_GeneralTypes.h | < | < |

⌋

42. Fr_SlotAssignmentType¶

Definition of datatype Fr_SlotAssignmentType ⌈ | Name | Fr_SlotAssignmentType | < | |---|---|---| | Kind | Structure | < | | Elements | Cycle | < | | ^ | Type | uint8 | | ^ | Comment | Cycle in which the frame is transmitted / received. | | ^ | SlotId | < | | ^ | Type | uint16 | | ^ | Comment | Slot ID of the frame. | | ^ | channelId | < | | ^ | Type | Fr_ChannelType | | ^ | Comment | Channel of the frame. | | Description | This structure contains information about the assignment of a FlexRay frame to a cycle and a slot ID. | < | | Available via | Fr_GeneralTypes.h | < |

⌋

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

功能定义
Fr_Init
Fr_ControllerInit
Fr_StartCommunication
Fr_AllowColdstart
Fr_AllSlots
Fr_HaltCommunication
Fr_AbortCommunication
Fr_SendWUP
Fr_SetWakeupChannel
Fr_GetPOCStatus
Fr_TransmitTxLPdu
Fr_CancelTxLPdu
Fr_ReceiveRxLPdu
Fr_CheckTxLPduStatus
Fr_PrepareLPdu
Fr_ReconfigLPdu
Fr_DisableLPdu
Fr_GetGlobalTime
Fr_GetNmVector
Fr_GetNumOfStartupFrames
Fr_GetChannelStatus
Fr_GetClockCorrection
Fr_GetSyncFrameList
Fr_GetWakeupRxStatus
Fr_SetAbsoluteTimer
Fr_CancelAbsoluteTimer
Fr_EnableAbsoluteTimerIRQ
Fr_AckAbsoluteTimerIRQ
Fr_DisableAbsoluteTimerIRQ
Fr_GetAbsoluteTimerIRQStatus
Fr_GetVersionInfo
Fr_ReadCCConfig
Callback 通知
Scheduled functions
Expected 接口
Mandatory 接口
Optional 接口
Configurable 接口
服务接口
时序图
配置规范
How to read this chapter
Containers and 配置 parameters
Fr
FrGeneral
FrController
FrAbsoluteTimer
FrControllerDemEventParameterRefs
FrFifo
FrRange
FrMultipleConfiguration
发布信息
附录
不适用需求
Change history of AUTOSAR traceable items
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
Added Constraints in R25-11
Changed Constraints in R25-11
Deleted Constraints 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
Added Constraints in R24-11
Changed Constraints in R24-11
Deleted Constraints in R24-11

Specification of FlexRay Driver (FlexRayDriver)¶