Standard Types (Std_Types)

The module std provides platform-wide uniform types and constants via Std_Types.h, but contains neither code nor configuration. Central is Std_ReturnType (uint8) with E_OK and E_NOT_OK. Modules may define their own values only in the range 0x02–0x3F with module prefix, because bit 7 and bit 8 are reserved for the RTE [SWS_Std_00011]. In addition, the module provides the constants STD_HIGH/STD_LOW, STD_ON/STD_OFF, and STD_ACTIVE/STD_IDLE, the type Std_VersionInfoType for version querying, as well as transformer and message types for client-server communication. In R20-11, the header also includes Compiler.h SRS BSWGeneral p. 62.

more ›

The module std is a pure type header. Via Std_Types.h it provides types and symbols, but no functions [SWS_Std_00005]. In R20-11, the header includes Platform_Types.h and Compiler.h and defines Std_ReturnType as well as the values E_OK/E_NOT_OK and the STD_* constants. Every module that uses these types includes it SRS BSWGeneral p. 62. According to a later version of the specification, there is no configuration and no dedicated error handling; this is likely to apply to R20-11 as well (interpretation) SWS StandardTypes p. 27. Question (open)

Context diagram: Std_Types.h as a common type base for BSW modules, CDDs, RTE, and transformers. Sources: SRS BSWGeneral p. 62, CDD Guideline p. 14

The core of the module is Std_ReturnType (uint8) with the values E_OK (0) and E_NOT_OK (1). The range 0x02–0x3F is intended for module-specific errors with module prefix; bit 7 and bit 8 are defined by the RTE specification [SWS_Std_00011]. Examples of such extensions are CAN_BUSY and Csm_ReturnType BSWUML Guide p. 29. Due to OSEK, E_OK is guarded via STATUSTYPEDEFINED [SWS_Std_00006].

Context diagram (type structure): default values, module-specific range, and RTE-reserved bits of Std_ReturnType. Sources: [SWS_Std_00005], [SWS_Std_00011], SWS StandardTypes p. 15

In addition, there are three pairs of constants, each with 0x01u/0x00u: STD_HIGH/STD_LOW for physical levels, STD_ON/STD_OFF as switches, and STD_ACTIVE/STD_IDLE for logical states ([SWS_Std_00007], [SWS_Std_00010], [SWS_Std_00013]). Std_VersionInfoType transports vendor ID, module ID, and software version for the synchronous, reentrant function <Ma>_GetVersionInfo [SWS_Std_00015].

For data transformation, std defines two types for transformer errors: Std_TransformerError, a structure consisting of error code and transformer class, and Std_TransformerClass [SWS_Std_00021]. The RTE passes this error on via the optional parameter transformerError SWS RTE p. 731. For client-server communication, Std_MessageTypeType and Std_MessageResultType encode request/response and OK/ERROR. A function pointer of type Std_ExtractProtocolHeaderFieldsType reads both values from a transformer header [SWS_Std_91003]. The forward types are still draft in R20-11 [SWS_Std_00029].

more ›

Role and system boundary: a pure type header without runtime behavior

The std module (Standard Types) contains no functions. It exclusively provides types and symbols that are available via Std_Types.h. Every requirement of the module names this header as its source, such as [SWS_Std_00005] and [SWS_Std_00015]. The specification explicitly states: the header provides no code and requires no other BSW modules; it has no configuration and no error handling of its own SWS StandardTypes p. 27. These wordings originate from the version starting with R23-11. The same is likely to apply to R20-11 because the R20-11 requirements contain exclusively type and symbol definitions (interpretation). Question Q-8e4c66ae80752d38 (open)

The purpose is standardized, platform-wide access to standard types. The BSW requirement for the standard type header therefore demands: every module that uses AUTOSAR integer types or the standard return type includes Std_Types.h SRS BSWGeneral p. 62. The return type Std_ReturnType is explicitly shared between the RTE and BSW modules [SWS_Std_00005]. In the methodology, the standard types are additionally described as the ARXML artifact "AUTOSAR Standard Types" Methodology p. 400.

Context diagram: Std_Types.h includes platform and compiler headers and is used by BSW modules, CDDs, RTE, and transformers as a common type base. Sources: SRS BSWGeneral p. 62, CDD Guideline p. 14, [SWS_Std_00005], [SWS_Std_00021]

Structure of Std_Types.h and inclusion in the header tree

For R20-11, the BSW requirement defines what Std_Types.h must provide SRS BSWGeneral p. 62:

• include the platform-specific type header Platform_Types.h,
• include the compiler-specific header Compiler.h,
• define Std_ReturnType,
• specify values for E_OK, E_NOT_OK, STD_ON, STD_OFF, STD_HIGH, STD_LOW, STD_ACTIVE, and STD_IDLE.

In the later version of the same requirement, the inclusion of Compiler.h is missing RS BSWGeneral p. 60. This matches the change history: in R22-11, the obsolete compiler abstraction was removed from a Std requirement, and NULL_PTR was only added with R21-11 SWS StandardTypes p. 1. For R20-11, Compiler.h is therefore part of the include chain, whereas a NULL_PTR from Std_Types.h is not yet.

A special case concerns E_OK. The symbol is already defined in OSEK and must therefore be shared. [SWS_Std_00006] prescribes protection via STATUSTYPEDEFINED: within the protection, E_OK (0x00u) and StatusType are defined; E_NOT_OK (0x01u) is outside. The BSW requirement contains the same implementation note with reference to ISO 17356-3 SRS BSWGeneral p. 62. How a Complex Device Driver places the header into its include structure is shown in the diagram of the CDD header structure CDD Guideline p. 14.

Std_ReturnType: Value range, bit layout, and module-specific extensions

Std_ReturnType is derived from uint8. The default values are E_OK (0) and E_NOT_OK (1); the range 0x02–0x3F is available for user-specific errors [SWS_Std_00005]. [SWS_Std_00011] refines this rule:

• Normally, the type is used with E_OK or E_NOT_OK.
• If these values are not sufficient, custom values may be defined in the six low-order bits, named with the module prefix.
• Bit 7 and bit 8 are reserved. Like the overall layout, they are defined by the RTE specification.

The diagram of the layout shows exactly this division SWS StandardTypes p. 15.

The RTE specification describes Std_ReturnType as the type for status and error values of API functions; the value 0 is reserved for "no error occurred" SWS RTE p. 675. According to the BSW modeling guide, it is the only return type permitted in client-server operations of service interfaces BSWUML Guide p. 28. An example of a module-specific extension is CAN_BUSY (0x02) of the CAN driver. Can_Write() returns this value if no transmit object is free SWS CANDriver p. 54.

Context diagram (type structure): Std_ReturnType is divided into default values, a module-specific range 0x02–0x3F, and two bits reserved by the RTE; module extensions such as Csm_ReturnType or CAN_BUSY occupy only the free range. Sources: [SWS_Std_00005], [SWS_Std_00011], SWS StandardTypes p. 15, BSWUML Guide p. 29, SWS CANDriver p. 54

In the UML model of the BSW, such an extension is modeled as class <Ma>_ReturnType with the stereotype «extra_literals». Its values bear the module prefix and lie in the range 0x02–0x3f BSWUML Guide p. 28. The example Csm_ReturnType with CSM_E_BUSY, CSM_E_SMALL_BUFFER, and CSM_E_ENTROPY_EXHAUSTION illustrates the pattern BSWUML Guide p. 29. If several modules of a stack require the same extension, it does not have to be defined separately for each module BSWUML Guide p. 33. The R23-11 version provides a generic class with «generic_type» for this purpose, from which the module-specific extensions are derived TR BSWUML Guide p. 37.

Activity diagram: decision whether and how a module extends Std_ReturnType with custom values. Sources: [SWS_Std_00011], BSWUML Guide p. 28, BSWUML Guide p. 33, TR BSWUML Guide p. 37

Symbolic constants for levels, switches, and states

In addition to the return values, Std_Types.h defines three pairs of constants. All three use the numerical values 0x01u and 0x00u, but are commented differently ([SWS_Std_00007], [SWS_Std_00010], [SWS_Std_00013]):

Pair	Values	Meaning according to definition
STD_HIGH / STD_LOW	0x01u / 0x00u	physical state 5 V or 3.3 V / 0 V
STD_ON / STD_OFF	0x01u / 0x00u	On/Off, without further comment
STD_ACTIVE / STD_IDLE	0x01u / 0x00u	logical state active / idle

A typical user of STD_HIGH/STD_LOW is the DIO driver: its read service returns exactly one of these two levels SWS DIO p. 37. STD_ON/STD_OFF serve as pre-compile switches. One example is EEP_21_LDEXT_VERSION_INFO_API STD_ON in the general BSW specification SWS BSWGeneral p. 76; another is the optional API switches of the GPT driver SWS GPT p. 48.

Version query via Std_VersionInfoType

Std_VersionInfoType is a structure with the following elements: vendorID and moduleID (uint16 each) as well as sw_major_version, sw_minor_version, and sw_patch_version (uint8 each). It is used via <Module name>_GetVersionInfo() to query the version of a BSW module [SWS_Std_00015]. The general BSW specification defines for this function SWS BSWGeneral p. 76:

• It operates synchronously and is reentrant.
• It has exactly one parameter of this type.
• Its availability is configured per module at pre-compile time via <Ma>VersionInfoApi.

The naming rule GetVersionInfo is stated in the BSW requirement with the example Eep_21_LDExt_GetVersionInfo SRS BSWGeneral p. 60.

Concrete implementations exist in many modules. When development error detection is enabled, Can_GetVersionInfo rejects a null pointer with CAN_E_PARAM_POINTER SWS CANDriver p. 57. Adc_GetVersionInfo checks accordingly for ADC_E_PARAM_POINTER SWS ADCDriver p. 80. The NVRAM manager shows the call as a simple synchronous exchange between user and module SWS NvM p. 158.

Sequence diagram: A user queries the version of a module synchronously; in case of a null pointer and active development error detection, the module reports an error, otherwise it populates Std_VersionInfoType. Sources: [SWS_Std_00015], SWS BSWGeneral p. 76, SWS CANDriver p. 57, SWS NvM p. 158

Transformer and message types for data transformation

std provides several types for transformer chains. In R20-11, Std_TransformerError is a structure consisting of errorCode (uint8) and transformerClass of type Std_TransformerClass [SWS_Std_00021]. Std_TransformerClass is derived from uint8 and knows five values [SWS_Std_00024]: STD_TRANSFORMER_UNSPECIFIED (0x00), STD_TRANSFORMER_SERIALIZER (0x01), STD_TRANSFORMER_SAFETY (0x02), STD_TRANSFORMER_SECURITY (0x03), and STD_TRANSFORMER_CUSTOM (0xFF).

The short signature in the API directory lists Std_TransformerError as typedef uint8. However, the structure definition of the requirement is authoritative. Later versions type errorCode as a separate type Std_TransformerErrorCode, whose meaning is determined per transformer chain SWS StandardTypes p. 17.

The RTE passes this type as an optional OUT parameter transformerError to its APIs, such as in Rte_Call SWS RTE p. 731, Rte_Read SWS RTE p. 720, and Rte_Result SWS RTE p. 750. The plug-in interfaces describe it as the error that occurred during the execution of the transformer chain SWS RTE p. 969.

Std_TransformerForward and Std_TransformerForwardCode are marked as draft in R20-11. The forward code recognizes E_OK, E_SAFETY_INVALID_REP, E_SAFETY_INVALID_SEQ, and E_SAFETY_INVALID_CRC ([SWS_Std_00027], [SWS_Std_00029]). In later versions, Rte_Send accepts an optional forwardedCode of this type SWS RTE p. 704. It presumably serves to re-map received safety errors during forwarding, as described by the E2E forward functions SWS E2ELibrary p. 107 (interpretation). According to the change history, the structure Std_TransformerForward was removed in R22-11 SWS StandardTypes p. 1. Question Q-f0d374b3b793c868 (open)

Sequence diagram: In addition to Std_ReturnType, a transformer error reaches the SW-C as Std_TransformerError with error code and transformer class. Sources: [SWS_Std_00021], [SWS_Std_00024], SWS RTE p. 731, SwCluster Guideline p. 245, SWS RTE p. 774

For client-server communication, there are two encoding types, in which 0x02–0x3F are each reserved for future values:

• Std_MessageTypeType distinguishes request (STD_MESSAGETYPE_REQUEST, 0x00) and response (STD_MESSAGETYPE_RESPONSE, 0x01) ([SWS_Std_91001], [SWS_Std_00017]).
• Std_MessageResultType encodes the result of a response: STD_MESSAGERESULT_OK (0x00) or STD_MESSAGERESULT_ERROR (0x01) ([SWS_Std_91002], [SWS_Std_00019]).

The function pointer type Std_ExtractProtocolHeaderFieldsType describes a synchronous, reentrant function. It extracts both values from the protocol header of a transformer in a buffer and returns a Std_ReturnType [SWS_Std_91003]. Transformers optionally receive such a pointer as an argument to their inverse function ASWS TransformerGeneral p. 40. The SOME/IP transformer provides a suitable implementation with SomeIpXf_ExtractProtocolHeaderFields SWS SOMEIPTransformer p. 61. The E2E profiles 4m, 7m, 8m, and 44m evaluate both values in their check functions SWS E2ELibrary p. 108.

Sequence diagram: For PXXm profiles, the E2E transformer extracts the message type and result via the passed function pointer and continues checking only for E_OK. Sources: [SWS_Std_91003], ASWS TransformerGeneral p. 40, SWS E2ETransformer p. 45, SWS SOMEIPTransformer p. 61, SWS E2ELibrary p. 108

Behavior in the event of an error

The module itself neither detects nor reports errors. The version starting with R23-11 states that the standard types provide no error handling and support no security events SWS StandardTypes p. 27; the same is likely to apply to R20-11 (interpretation). Question (open) Therefore, error behavior only arises in the modules that use the types. The basic signal is E_NOT_OK [SWS_Std_00006]; its concrete meaning is defined by the respective API. For Adc_ReadGroup, it means "no results available or development error" SWS ADCDriver p. 61; for CanIf_Transmit, "transmit request not accepted" SWS CANInterface p. 87.

More detailed error patterns are reported via module-specific values in the range 0x02–0x3F [SWS_Std_00011], for example CAN_BUSY SWS CANDriver p. 54. Callers must therefore expect a Std_ReturnType to assume more than two values. A special case is callbacks routed via the RTE as AUTOSAR services: although the caller may assume E_OK, such callbacks can fail, for instance, in partitioned systems SWS BSWGeneral p. 69.

In transformer chains, an error is reported in addition to the return value via Std_TransformerError with error code and transformer class [SWS_Std_00021]. The RTE generates the optional parameter transformerError only if the error handling transformerErrorHandling is configured for the port SWS RTE p. 774. If extracting the header fields fails, SomeIpXf_ExtractProtocolHeaderFields returns E_NOT_OK, such as in the case of an incorrect protocol version or a buffer that is too short SWS SOMEIPTransformer p. 61. The E2E transformer logic continues checking only upon E_OK SWS E2ETransformer p. 45.

Further detailed evidence

• [SWS_Std_00005], [SWS_Std_00006], [SWS_Std_00011]: return type, default values with OSEK protection, bit layout, and extension rule.
• [SWS_Std_00007], [SWS_Std_00010], [SWS_Std_00013]: the three pairs of constants for physical levels, switches, and logical states.
• [SWS_Std_00015] together with SWS BSWGeneral p. 76: version structure and rules for GetVersionInfo.
• [SWS_Std_00021], [SWS_Std_00024], [SWS_Std_00027], [SWS_Std_00029]: transformer error and forward types; the latter two are draft.
• [SWS_Std_91001], [SWS_Std_91002], [SWS_Std_91003], [SWS_Std_00017], [SWS_Std_00019]: message types and header extraction for C/S communication.
• SRS BSWGeneral p. 62: content and include chain of Std_Types.h in R20-11.
• SWS StandardTypes p. 27 and SWS StandardTypes p. 1: missing configuration and error handling as well as change history (later releases).