Real-Time Workshop® Embedded Coder™rtw.connectivity.RtIOStreamHostCommunicator   runValidation (C++ Encapsulation Interface Control)
  

runValidation (AUTOSAR) - Validate RTW.AutosarInterface object against model

Syntax 

[status, msg] = autosarInterfaceObj.runValidation

Description

runValidation is a method of the class RTW.AutosarInterface.

[Status, Message] = autosarInterfaceObj.runValidation runs a validation check for the RTW.AutosarInterface object against the model to which the object is attached. Before calling this method, you must call the attachToModel method.

autosarInterfaceObj is a model-specific RTW.AutosarInterface object.

Status returns a status flag indicating whether the configuration is valid. If valid, status is true; otherwise, it is false.

Message: If the returned status flag is false, Message stores the explanation of why the configuration is invalid.

The method runValidation performs the checks described in the following tables. The first table describes validation checks for all AUTOSAR use cases, and the second table describes specific validation checks when exporting multiple runnable entities.

Validation Checks

GroupCheck
Valid names and paths

Runnable names and event names must all be unique, and must be valid AUTOSAR short name identifiers (see definition 1 following).

AUTOSAR port, interface, and data element names must be valid AUTOSAR short name identifiers (see definition 1 following).

AUTOSAR XML options for the component name, internal behavior name, and implementation name must be valid AUTOSAR path and short name identifiers (see definition 2 following).

AUTOSAR XML options for the interface package name and data type package name must be valid AUTOSAR path identifiers (see definition 3 following).

Valid names and paths for sender/receiver ports

For sender/receiver ports (Implicit or explicit data access mode):

  • Simulink ports may have duplicated AUTOSAR port names, however the AUTOSAR Interface name must also be the same.

  • A Simulink inport and an outport cannot have the same AUTOSAR port name.

  • For any duplicated AUTOSAR port name and AUTOSAR Interface name, the Data element names must be unique.

  • Sender/receiver ports AUTOSAR port name cannot be the same as the ServiceName of a basic software port.

  • Sender/receiver ports AUTOSAR port name and Interface cannot be the same as the port name or interface of a calibration object.

  • Sender/receiver ports Interface plus XML Option Interface package (e.g., of the form AUTOSAR/Service/servicename) cannot be the same as the ServiceInterface of a basic software port.

Valid names and paths for basic software portsFor basic software ports:

  • ServiceName and ServiceOperation must be valid AUTOSAR short name identifiers (see definition 1 following); and ServiceInterface must be a valid AUTOSAR path identifier (see definition 3 following).

  • Simulink ports may have duplicated ServiceName, however the ServiceInterface must also be the same.

  • For any duplicated ServiceName and ServiceInterface, the ServiceOperation must be unique.

  • For duplicated ServiceOperation and ServiceInterface, the ServiceName must be unique.

  • Basic software port ServiceName name and ServiceInterface cannot be the same as the port name or interface of a calibration object.

Unsupported featuresModel must not contain custom code blocks.
Model must not contain continuous time.
Model must not contain non-inlined S-functions.
Model must not contain non-finite numbers.
Model must not contain complex numbers.
Model must not contain multitasking
Model must not contain asynchronous rates
Storage class of root I/O ports must be auto.
I/O must be 1D or scalar.
The sample time of a runnable must be a positive real scalar. Sample times with offset, e.g. [2 1], cause an error message.
Error status validationAn error status inport cannot point to itself (i.e., cannot specify itself as the inport for which it permits access to error status ).
Error status inports can only be defined to correspond to other inports that have Data Access Mode set to ImplicitReceive or ExplicitReceive
Each receiver port can have only one error status port designate it as its error status.

Definitions of requirements for identifiers:

  1. AUTOSAR short name identifiers must be composed of at most 32 characters, must begin with a letter, and can contain only letters, numbers, and underscore characters. For example, this_is_valid123.

  2. AUTOSAR path and short name identifiers must contain at least two path delimiter "/" characters, e.g., /path/shortname. Strings in between the path delimiters must be composed of at most 32 characters, must begin with a letter, and can contain only letters, numbers, and underscore characters.

  3. AUTOSAR path identifiers must contain at least one path delimiter "/" characters, e.g., /path. Strings in between the path delimiters must be composed of at most 32 characters, must begin with a letter and can contain only letters, numbers, and underscore characters.

Multiple Runnable Validation Checks

GroupCheck
Wrapper subsystem validation when exporting multiple runnables.
The "wrapper subsystem" is the top diagram runnables are exported from.		"Top-level" function-call subsystems (that are in the top diagram of the wrapper subsystem) must not be reusable functions. Their 'RTW System code' option must be set to 'Auto', 'Function' or 'Inline'.
Top-level function-call subsystems cannot emit function calls.
The only subsystems allowed at the top diagram are function-call subsystems, and empty subsystems (e.g., subsystems that contain no executable blocks, which may be used to display text in the model, or to double-click for help callback.)
Top-level function-call subsystems cannot have wide trigger ports.
A signal connected to an outport of the wrapper subsystem cannot have multiple destinations. The signal must have one destination that is uniquely a sender, service, or interrunnable variable.
A signal connected to an outport of the wrapper subsystem cannot have an inport of that subsystem as its source.
All data store memory blocks referenced from subsystems must be contained in the subsystems, to prevent data integrity issues.
All lines must be contiguous. No line in the wrapper subsystem can be an output of a virtual bus creator or mux block
Constant blocks are not allowed in the wrapper subsystem.
No mux, or demux blocks are allowed in the wrapper subsystem, because the signals being passed via the runnable I/O must be contiguous and have an address at the base of the array.
Wrapper level Merge block validationMerge blocks have some restrictions at wrapper level:

  • A merge block is only allowed in the wrapper subsystem when the merge block output is connected to a diagram outport (not another Merge block).

  • The input to a Merge block in the wrapper subsystem must be connected to a function-call subsystem outport.

  • The input to a Merge block in the wrapper subsystem does not need a label.

  • A merge block in the wrapper subsystem cannot merge signals of unequal widths.

  • You cannot connect a Merge block in the wrapper subsystem to more than one outport of any given function-call subsystem.

Other multiple runnable validation checks

All runnable names, event names, and interrunnable variable names must be unique. Lines representing interrunnable variables must be labeled with valid AUTOSAR short name identifiers. No goto-from pairs are allowed because then the signal label is not unique.

Interrunnable variables cannot be structs. All interrunnable variables must be scalar, non-complex types. This is required by the AUTOSAR specification.

Signal lines that connect two top-level function-call subsystems represent interrunnable variables.

Function-call subsystem output cannot be connected to its own input. An output of a function-call subsystem inside the wrapper subsystem cannot be connected to an input of same subsystem.

The blocks in the top diagram of the wrapper subsystem must not have unconnected ports.

Any top-level input that is Explicit Receive, Error Status, or Basic Software Service cannot be connected to more than one inport of any given function-call subsystem.

The sample time of the inport associated with an error status must be the same sample time as its corresponding data port.
Each function call subsystem being exported as a runnable entity must specify an AUTOSAR interface.

  

rtw.connectivity.RtIOStreamHostCommunicatorrtw.connectivity.RtIOStreamHostCommunicator runValidation (C++ Encapsulation Interface Control)runValidation (C++ Encapsulation Interface Control)

 © 1984-2008- The MathWorks, Inc.    -   Site Help   -   Patents   -   Trademarks   -   Privacy Policy   -   Preventing Piracy   -   RSS