[技术总结] AUTOSAR CP - BSW (Basic Software) - AutoSar OS - Scheduler

From: ../standards/R3.2.3/CP/AUTOSAR_SWS_BSW_Scheduler.pdf

1 Introduction and functional overview

This specification specifies the functionality, API and the configuration of the AUTOSAR Basic Software module BSW Scheduler.
It does neither specify nor recommend a particular implementation of the BSW Scheduler.

Figure 1 shows the position of the BSW Scheduler within the AUTOSAR Layered Software Architecture (see [2]).
The BSW Scheduler is part of the System Services and provides therefore services for all modules of all layers.

image
Figure 1: Position of the BSW Scheduler in the AUTOSAR Layered Software Architecture

However, unlike the other BSW modules, the BSW Scheduler offers concepts and services for the integration.
Hence, this central module provides means to

  • embed BSW module implementations into the AUTOSAR OS context
  • trigger main processing functions of the BSW modules
  • apply data consistency mechanisms for the BSW modules

The integrator’s task is to apply given means (of the AUTOSAR OS) in order to assemble BSW modules in a well-defined and efficient manner in a project specific context.

This also means that the BSW Scheduler only uses the AUTOSAR OS. It is not in the least a competing entity for the AUTOSAR OS scheduler.\

Example 1.1: The BSW Scheduler uses the concept of the AUTOSAR OS ‘Task’ to
implement the concept ‘Triggering of a BSW main processing function’. 

Example 1.2: The BSW Scheduler uses the AUTOSAR OS services ‘DisableAllInterrupts’ and ‘EnableAllInterrupts’ to implement the BSW Scheduler services for entering and/or exiting a sequence of non-preemptable instructions.

The implementation of the BSW Scheduler is based on

  • the BSW Module Description of the BSW modules
  • the configuration of the BSW Scheduler
Example 1.3: The BSW Module Description depicts the BSW module Module by two main processing functions <Module>_MainFunction_Transmit and <Module>_MainFunction_Receive, beside others

Example 1.4: The BSW Scheduler implements the triggering of two main processing functions 
- <Module1>_MainFunction 
- and <Module2>_MainFunction 
by calling them in a Task Task_8ms. 
The Task Task_8ms calls <Module1>_MainFunction before <Module2>_MainFunction. 
The implementation of the BSW Scheduler module activates the Task Task_8ms cyclically every eight millisecond. This means, the configuration of the BSW Scheduler mainly determines its implementation.

2 Acronyms and abbreviations

3 Related documentation

4 Constraints and assumptions

4.1 Limitations

This specification assumes that all modules of the AUTOSAR Basic Software run in the same OS-Application (see [7] for details).

4.2 Applicability to car domains

There are no explicit restrictions for the applicability to car domains.

5 Dependencies to other modules

As explained in the introduction chapter, the BSW Scheduler is the central integration entity. Therefore, the BSW Scheduler has dependencies on all BSW modules; whereas two different dependency types

  • use dependencies
  • and realize dependencies (as seen from the BSW Scheduler)

are distinguished.

INTEGR004: Use dependencies:
The BSW Scheduler uses the main processing functions of the BSW modules in the sense that the AUTOSAR OS objects ‘Task’ call them.
The AUTOSAR OS is a particular module because the BSW Scheduler uses
its entire functionality.

INTEGR005: Realize dependencies:
The BSW Scheduler provides services (APIs) for all other BSW modules, except for the AUTOSAR OS.
Hence, the BSW Scheduler realizes functionality for those BSW modules (see Chapter 8.3).

BSW Scheduler  -- service --> all other BSW modules. 
except for the AUTOSAR OS.

From an architectural point of view, there currently exists no relationship between the RTE and the BSW Scheduler. This may be a weakness in the architecture because of the following reasons:

  • The RTE provides the infrastructure for Software Components, i.e. the RTE
    embeds runnable entities in a task context.
  • The BSW Scheduler provides the infrastructure for the BSW modules, i.e. the BSW Scheduler embeds main processing function in a task context.

However, with the current architecture, runnable entities and main processing functions cannot be embedded in the same task.

Anchor:
Not clear.

5.1 File structure

5.1.1 Code file structure

5.1.2 Header file structure

Figure 2: Header file structure of the BSW Scheduler
Figure 3: Header file structure of a BSW module .c

5.1.3 Process description (informative)

Figure 4: Development process from an implementer’s point-of-view
Figure 5: Integration process from an integrators point-of-view

5.1.4 Basic Software Module Description Template (informative)

...

  • name and list potentially shared resources
  • name and list all (internal) entities that access these particular resources
  • establish a connection between entities of other modules and the entry points that finally access shared resources
  • assumptions on the implementations of critical sections (ExclusiveAreas)
  • take ‘possible’ task contexts of the resource access into account
  • and other issues
    ...
    This means that there are three different layers:
    • module/interface level describing the entities of the module
    • behavior level describing the triggers of schedulable objects and means for ensuring data consistency (ExclusiveAreas)
    • implementation level describing the memory consumption, the timing of a specific implementation etc.
      ...
      Figure 6: Classification of BSW module entities

6 Requirements traceability

7 Functional specification

7.1 Embedding main processing functions into the AUTOSAR OS context

7.1.1 General considerations

7.1.2 Triggering main processing functions

7.1.2.1 General concepts

In general, main processing functions, as schedulable objects, shall react on specific trigger conditions. The BSW Module Description (Template) models trigger conditions as so-called BswEvents. Currently, the concept of BswEvents distinguishes two different types (see Figure 7):

  • BswSporadicEvents - comprising triggers that appear occasionally
  • BswCyclicEvents - comprising triggers that recur cyclically
    ...
    Figure 7: Types of BswEvents
    Figure 8: Interactions of BswEvents and BswSchedulableEntities
    ...

7.1.2.2 BswCyclicEvents

7.1.2.2.1 Background

The concept of BswCyclicEvents depicts the ability to process recurring events. The following classes of BswCyclicEvents are possible:

  • fixed or variable cyclic recurring events where the type of trigger condition is Time, in the document referred to as timed BswCyclicEvents,
  • recurring events where the type of trigger condition only indirectly relates to Time (e.g. angle of a crankshaft)
7.1.2.2.2 Fixed cyclic BswCyclicEvents based on Time

The term ‘fixed cyclic’ means that a specific configured cycle time shall not change during runtime.
...
The BSW Scheduler is not responsible for the lifecycle management. The AUTOSAR OS scheduler manages and schedules the AUTOSAR OS objects ‘Task’.

Anchor: 
not clear.

Example 7.3: Two main processing functions Com_MainFunction_Receive ()
and Com_MainFunction_Transmit () shall process every seven millisecond.

The BSW Scheduler module implements this by using the AUTOSAR OS objects
‘Task’ and ‘Alarm’

Implementation of the BSW Scheduler module:

  • AUTOSAR OS configuration:
COUNTER SYSTEM_COUNTER {
 /* 1MS system counter */
 MAXALLOWEDVALUE = 65535;
 TICKSPERBASE = 1000000;
 MINCYCLE = 1;
};
ALARM TASK_7MS {
 COUNTER = SYSTEM_COUNTER;
 ACTION = ACTIVATETASK {
 TASK = Task_7ms;
 };
};
  • SchM_cfg.h:
#define START_TIME_7MS 0
#define CYCLE_TIME_7MS 7
  • SchM.c:
void
SchM_Init () {
 SetRelAlarm (TASK_7MS, START_TIME_7MS, CYCLE_TIME_7MS);
}
TASK (Task_7ms) {
 ...
 Com_MainFunction_Receive ();
 Com_MainFunction_Transmit ();
 ...
}
7.1.2.2.3 Variable cyclic BswCyclicEvents based on Time

Variable cyclic here means that the cycle time might be mode dependent and might vary during runtime.
Thus, the AUTOSAR OS object ‘ScheduleTable’ likely implements BswCyclicEvents with variable cycles.

7.1.2.2.4 BswCyclicEvents not directly based on Time

Since there are various use cases and therefore implementations possible, the implementation of this type of BswCyclicEvents is neither specified nor documented.

Anchor: 
not clear

7.1.2.3 BswSporadicEvents

7.1.2.3.1 Concept

Figure 9: ActivationPoints and CancellationPoints in the context of BswSporadicEvents

7.1.2.3.2 Implementation

Implementation of the BSW module :

  • <ModulePrefix>_cfg.h:
#define TIMEOUT_EVENT_100MS (1)
#define ACTIVATION_POINT_1 TIMEOUT_EVENT_100MS
  • <ModulePrefix>.c:
#include “<ModulePrefix>.h”
#include “<ModulePrefix>_cfg.h”
#include “SchM_<ModulePrefix>.h”
void
<ModulePrefix>_foo () {
 ...
 SchM_ActMainFunction_<ModulePrefix> (ACTIVATION_POINT_1);
 ...
}

Implementation alternative 1 of the BSW Scheduler module:
SchM_<ModulePrefix>.h:

#define SchM_ActMainFunction_<ModulePrefix> (ActivationPoint) \
 ActMainFunction_<ModulePrefix>_ ## ActivationPoint
#define ActMainFunction_<ModulePrefix>_1 \
 ActivateTask (<ModulePrefix>_MainFunction_<Name>Task)

SchM.c:

#include “<ModulePrefix>.h”
#include “SchM.h”
#include “SchM_<ModulePrefix>.h”
TASK (<ModulePrefix>_MainFunction_<Name>Task) {
 <ModulePrefix>_MainFunction_<Name> ();
 TerminateTask ();
}

...

7.1.2.4 Main processing functions triggered by BswCyclicEvents and BswSporadicEvents

...

7.2 Data consistency

7.2.1 Background

7.2.2 Built-in data consistency

7.2.3 ExclusiveAreas

7.2.3.1 Concept

Figure 10: BSW module description template extract concerning ExclusiveAreas

7.2.3.2 Implementation

7.3 Error handling concept

7.3.1 Background

7.3.2 Error handling in the context of AUTOSAR OS/OSEK

7.3.2.1 Fatal errors

7.3.2.2 Protection errors

7.3.2.3 Application errors

7.3.2.3.1 Development phase
7.3.2.3.2 Production phase

7.3.3 Error handling of the BSW Scheduler

7.3.3.1 Production errors

There are no production errors for the BSW Scheduler specified.

7.3.3.2 Development errors

8 API specification

8.1 Imported types

8.2 Type definitions

8.2.1 SchM_ReturnType

INTEGR070:

  • Name: SchM_ReturnType
  • Type: uint8
  • Range:
name value meaning
SCHM_E_OK 0x00 No error occurred.
SCHM_E_LIMIT 0x04 An internal limit has been exceeded.
SCHM_E_NOFUNC 0x05 Requested service has not the desired effect.
SCHM_E_STATE 0x07 Requested service is already in use.
  • Description: The values of this BSW Scheduler specific status type are aligned to the values of the AUTOSAR OS status types.

8.2.2 SchM_ConfigType

INTEGR083:

  • Name: SchM_ConfigType
  • Type: Structure
  • Range:
    ** Implementation specific structure
    ** Structure to hold the module’s configuration set. The contents of this data structure are implementation specific.
  • Description: Structure for the purpose of configuration.

8.3 Function definitions

8.3.1 SchM_Init

INTEGR023: The SchM_Init function shall allocate and initialize the resources to be used by the Scheduler Module. This function can also call OS services to trigger AUTOSAR OS ‘Tasks’.

INTEGR099:

name value
Service name: SchM_Init
Syntax: void SchM_Init()
Service ID[hex]: 0x00
Sync/Async: Synchronous
Reentrancy: Non Reentrant
Parameters (in): None
Parameters (in-out): None
Parameters (out): None
Return value: None
Description: Function for initialization of the SchM module.

8.3.2 SchM_Deinit

INTEGR027: The SchM_Deinit function shall finalize and free the resources used by the Scheduler Module.

INTEGR100:

name value
Service name: SchM_Deinit
Syntax: void SchM_Deinit()
Service ID[hex]: 0x01
Sync/Async: Synchronous
Reentrancy: Non Reentrant
Parameters (in): None
Parameters (in-out): None
Parameters (out): None
Return value: None
Description: Function for de-initialization of the SchM module.

8.3.3 SchM_GetVersionInfo

INTEGR101:

name value
Service name: SchM_GetVersionInfo
Syntax: void SchM_GetVersionInfo( Std_VersionInfoType* versioninfo )
Service ID[hex]: 0x02
Sync/Async: Synchronous
Reentrancy: Non Reentrant
Parameters (in): None
Parameters (in-out): None
Parameters (out): versioninfo: Pointer to the memory location holding the version information of the module
Return value: None
Description: Returns the version information of this module. 
Anchors: 
In above table, there is one example about what's "Parameters (out)".

INTEGR030: The SchM_GetVersionInfo function shall return the version information of this module. The version information includes:

  • Module Id
  • Vendor Id
  • Vendor specific version numbers (BSW00407).

INTEGR037: The parameter versionInfo of the SchM_GetVersionInfo function shall point to the memory location holding the version information of the module.

INTEGR031: The SchM_GetVersionInfo function shall be pre-compile time configurable On/Off by the configuration parameter SCHM_VERSION_INFO_API

Hint:
If source code for caller and callee of this function is available, this function should be realized as a macro. The macro should be defined in the modules header file.

8.3.4 SchM_Enter

INTEGR102:

name value
Service name: SchM_Enter_<ModulePrefix>
Syntax: void SchM_Enter_<ModulePrefix>(
uint8 Instance,
uint8 ExclusiveArea
)
Service ID[hex]: 0x03
Sync/Async: Synchronous
Reentrancy: Non Reentrant
Parameters (in): (1) Instance: Parameter for identifying a unique instance of the calling BSW module
(2) ExclusiveArea: Parameter for identify a unique internal resource of the BSW Module <ModulePrefix>
Parameters (in-out): None
Parameters (out): None
Return value: None
Description: Invokes the SchM_Enter function to enter a module local exclusive area.

INTEGR032: A BSW module <ModulePrefix> shall invoke the SchM_Enter function
to enter a module local exclusive area (also known as critical section).

Anchor:
Not clear.

INTEGR033: The SchM_Enter function shall expect a valid configuration of system resources in terms of OS objects. The BSW Scheduler shall use the AUTOSAR OS by default.

INTEGR051: The parameter Instance of the function SchM_Enter_<ModulePrefix> shall identify a unique instance of the calling BSW module <ModulePrefix>

INTEGR052: When calling the function SchM_Enter_<ModulePrefix>, a BSW
module <ModulePrefix> can omit the parameter Instance in case there is only one instance of the BSW module <ModulePrefix> possible.

INTEGR053: The parameter ExclusiveArea of the function
SchM_Enter_<ModulePrefix> shall identify a unique internal resource of the
BSW Module <ModulePrefix>.

Note: The configuration of the service SchM_Enter depends on the implementation of the BSW Scheduler Module. Because the implementation of the BSW Scheduler module belongs to the ECU integrators tasks, the implementation is mainly project specific.

8.3.5 SchM_Exit

INTEGR103:

name value
Service name: SchM_Exit_<ModulePrefix>
Syntax: void SchM_Enter_<ModulePrefix>(
uint8 Instance,
uint8 ExclusiveArea
)
Service ID[hex]: 0x04
Sync/Async: Synchronous
Reentrancy: Non Reentrant
Parameters (in): (1) Instance: Parameter for identifying a unique instance of the calling BSW module
(2) ExclusiveArea: Parameter for identifying a unique internal resource of the BSW Module to be protected
Parameters (in-out): None
Parameters (out): None
Return value: None
Description: Invokes the SchM_Exit function to exit an exclusive area.

INTEGR035: A BSW module shall invoke the SchM_Exit function to exit an exclusive area (also known as critical section).

INTEGR036: The SchM_Exit function shall expect a valid configuration of system resources in terms of OS objects. The BSW Scheduler shall use the AUTOSAR OS by default.

INTEGR054: The parameter Instance of the SchM_Exit_<ModulePrefix> function shall identify a unique instance of the calling BSW module <ModulePrefix>.

INTEGR056: When calling the function SchM_Exit_<ModulePrefix>, a BSW
module <ModulePrefix> can omit the parameter Instance in case there is only one instance of the BSW module <ModulePrefix> possible.

Anchor:
Not clear

INTEGR055: The parameter ExclusiveArea of the SchM_Exit_<ModulePrefix> function shall identify a unique internal resource of the BSW Module <ModulePrefix> to be protected.

Note: The configuration of the function SchM_Exit depends on the implementation of the BSW Scheduler Module. Because the implementation of the BSW scheduler module belongs to the ECU integrators tasks, the implementation is mainly project specific.

8.3.6 SchM_ActMainFunction

INTEGR104:

name value
Service name: SchM_ActMainFunction_<ModulePrefix>
Syntax: SchM_ReturnType SchM_ActMainFunction_<ModulePrefix>(
uint8 Instance,
uint8 ActivationPoint
)
Service ID[hex]: 0x05
Sync/Async: Synchronous
Reentrancy: Non Reentrant
Parameters (in): (1) Instance: Parameter for identifying a unique instance of the calling BSW module
(2) ActivationPoint: Parameter for identifying the unique execution point which invokes SchM_ActMainFunction_<ModulePrefix>
Parameters (in-out): None
Parameters (out): None
Return value: SchM_ReturnType:

SCHM_E_OK: No error occurred.
SCHM_E_LIMIT: To many task activation (of the task context of the main processing function)
SCHM_E_STATE: ActivationPoint is already in use.
Description: Invokes the SchM_ActMainFunction function to trigger the activation of a corresponding main processing function.

INTEGR039: A BSW module implementation shall invoke the SchM_ActMainFunction function to trigger the activation of a corresponding main processing function.

INTEGR064: The SchM_ActMainFunction function shall expect a valid confiuguration of system resources in terms of OS objects. The BSW Scheduler shall use the AUTOSAR OS by default.

INTEGR057: The parameter Instance of the SchM_ActMainFunction_<ModulePrefix> function shall identify a unique instance of the calling BSW module <ModulePrefix>.

INTEGR058: When calling the function SchM_ActMainFunction_<ModulePrefix>, a BSW module can omit the parameter Instance in case there is only one instance of the BSW module <MulePrefix> possible.

Anchor:
not clear.

INTEGR061: The parameter ActivationPoint of the function
SchM_ActMainFunction_<ModulePrefix> shall identify the unique execution
point which invokes SchM_ActMainFunction_<ModulePrefix>.

The BSW Module Description shall bind the ActivationPoint to a BswSporadicEvent containing the attribute:

  • the minimum delay time (given in time units, ticks …) until activation of a main processing function
    A BswSporadicEvent is then able to activate a main processing function.
Note The configuration of the service SchM_ActMainFunction depends on the implementation of the BSW Scheduler Module. Because the implementation of the BSW Scheduler module belongs to the ECU integrators tasks, the implementation is mainly project specific.

8.3.7 SchM_CancelMainFunction

INTEGR105:

name value
Service name: SchM_CancelMainFunction_<ModulePrefix>
Syntax: SchM_ReturnType SchM_CancelMainFunction_<ModulePrefix>(
uint8 Instance,
uint8 ActivationPoint
)
Service ID[hex]: 0x06
Sync/Async: Synchronous
Reentrancy: Non Reentrant
Parameters (in): (1) Instance: Parameter for identifying a unique instance of the calling BSW module
(2) ActivationPoint: Parameter refering to the corresponding ActivationPoint of SchM_ActMainFunction_<ModulePrefix> to be canceled
Parameters (in-out): None
Parameters (out): None
Return value: SchM_ReturnType:

SCHM_E_OK: No error occurred.
SCHM_E_NOFUNC : Currently, there is no activation of a main processing function for the given ActivationPoint pending.
Description: Invokes the SchM_CancelMainFunction function to trigger the cancellation of the requested activation of a corresponding main processing function.

INTEGR044: A BSW module shall invoke the SchM_CancelMainFunction function
to trigger the cancellation of the requested activation of a corresponding main processing function.

INTEGR063: The SchM_CancelMainFunction function shall have no effect on an
ActivationPoint where the content of the ‘delay attribute’ is zero (0 time units, ticks…), at all. In this case, the service shall return with value SCHM_E_NOFUNC.

INTEGR066: The SchM_CancelMainFunction function shall expect a valid configuration of system resources in terms of OS objects. The BSW Scheduler shall use the AUTOSAR OS by default.

INTEGR059: The parameter Instance of the function SchM_CancelMainFunction_<ModulePrefix> shall identify a unique instance of the calling BSW module <ModulePrefix>.

INTEGR060: When calling the function SchM_CancelMainFunction_<ModulePrefix>, a BSW module can omit the parameter Instance in case there is only one instance of the BSW module <ModulePrefix> possible.

INTEGR062: The parameter ActivationPoint of the function SchM_CancelMainFunction_<ModulePrefix> shall refer to the corresponding
ActivationPoint of SchM_ActMainFunction_<ModulePrefix> to be canceled.

Note: The configuration of the service SchM_CancelMainFunction depends on the implementation of the BSW Scheduler Module. Because the implementation of the BSW Scheduler module belongs to the ECU integrators tasks, the implementation is mainly project specific.

8.4 Call-back notifications

Not applicable

8.5 Scheduled functions

Not applicable

8.6 Expected Interfaces

This chapter lists all interfaces required from other modules.

8.6.1 Mandatory Interfaces

This chapter defines all interfaces which are required to fulfill the core functionality of the module.
INTEGR106:

API function Module Description
<ModulePrefix>_MainFunction_<…> all The BSW Scheduler Module needs to access all main processing functions of all modules. The BSW Scheduler Module implements or triggers their invocation.

8.6.2 Optional Interfaces

This chapter defines all interfaces which are required to fulfill an optional functionality of the module.
INTEGR107:

API function Description
Det_ReportError Service to report development errors.

8.6.3 Configurable interfaces

This chapter lists all interfaces, which are potentially configurable. This is usually a callback function whereas the name is configurable.
Not applicable

9 Sequence diagrams

With respect to data consistency, this section contains two sequence diagrams:

  • One sequence diagram as an example for a globally accessible resource
  • and one sequence diagram as an example for a locally accessible resource.

Example: Globally accessible buffer:
Example: Locally accessible buffer:

10 Configuration specification

In general, this chapter defines configuration parameters and their clustering into containers. In order to support the specification

  • Chapter 10.1 describes fundamentals. It also specifies a template (table) you shall use for the parameter specification.
    We intend to leave Chapter 10.1 in the specification to guarantee comprehension.
  • Chapter 10.2 specifies the structure (containers) and the parameters of the module Scheduler Module.
  • Chapter 10.3 specifies published information of the module Scheduler Module.

10.1 How to read this chapter

In addition to this section, it is highly recommended to read the documents:

  • AUTOSAR Layered Software [2]
  • AUTOSAR ECU Configuration Specification [6]
    This document describes the AUTOSAR configuration methodology and the
    AUTOSAR configuration meta-model in detail.

The following is only a short survey of the topic and it will not replace the ECU Configuration Specification document.

10.1.1 Configuration and configuration parameters

Configuration parameters define the variability of the generic part(s) of an implementation of a module. This means that only generic or configurable module implementation can be adapted to the environment (software/hardware) in use during system and/or ECU configuration.

The configuration of parameters can be achieved at different times during the software process:

  • before compile time,
  • before link time
  • or after build time.

In the following, the term “configuration class” (of a parameter) shall be used in order to refer to a specific configuration point in time.

10.1.2 Variants

Variants describe sets of configuration parameters.
E.g.,

  • variant 1: only pre-compile time configuration parameters;
  • variant 2: mix of pre-compile- and post build time configuration parameters.

In one variant a parameter can only be of one configuration class.

10.1.3 Containers

Containers structure the set of configuration parameters.
This means:

  • all configuration parameters are kept in containers.
  • (sub-) containers can reference (sub-) containers.
    It is possible to assign a multiplicity to these references.
    The multiplicity then defines the possible number of instances of the contained parameters.

10.2 Containers and configuration parameters

The following chapters summarize all configuration parameters. The detailed meanings of the parameters describe Chapters 7 and Chapter 8.

10.2.1 Variants

INTEGR108:
Variant 1: This variant only allows pre-compile time parameters.
Variant 2: none
Variant 3: none

10.2.2 SchM

10.2.3 SchMGeneral

10.2.4 SchMMainFunctionMapping

10.2.5 SchMScheduleTableMapping

10.2.6 SchMModuleConfiguration

10.2.7 InstanceConfiguration

10.2.8 ExclusiveAreaConf

10.2.9 ActivationPointConf

10.2.10 CancelationPointConf

10.2.11 SporadicEventConf

10.3 Published Information

Published information contains data defined by the implementer of the SW module that does not change when the module is adapted (i.e. configured) to the actual HW/SW environment. It thus contains version and manufacturer information.
The standard common published information like

  • vendorId (_VENDOR_ID),
  • moduleId (_MODULE_ID),
  • arMajorVersion (_AR_MAJOR_VERSION),
  • arMinorVersion (_ AR_MINOR_VERSION),
  • arPatchVersion (_ AR_PATCH_VERSION),
  • swMajorVersion (_SW_MAJOR_VERSION),
  • swMinorVersion (_ SW_MINOR_VERSION),
  • swPatchVersion (_ SW_PATCH_VERSION),
  • vendorApiInfix (_VENDOR_API_INFIX)

is provided in the BSW Module Description Template (see [9] Figure 4.1 and Figure 7.1).
Additional published parameters are listed below if applicable for this module.

11 Changes to Release 3.0

...

12 Changes during SWS Improvements by Technical Office

...

posted on 2025-06-29 23:10  s21  阅读(37)  评论(0)    收藏  举报

导航