RTA-RTE Reference Manual

RTA-RTE Reference Manual
RTA-RTE V6.2.0
Reference Manual
RTA-RTE V6.2.0
Reference Manual
Copyright
The data in this document may not be altered or amended without special notification
from ETAS GmbH. ETAS GmbH undertakes no further obligation in relation to this document. The software described in it can only be used if the customer is in possession
of a general license agreement or single license. Using and copying is only allowed in
concurrence with the specifications stipulated in the contract. Under no circumstances
may any part of this document be copied, reproduced, transmitted, stored in a retrieval
system or translated into another language without the express written permission of
ETAS GmbH.
©Copyright 2017 ETAS GmbH, Stuttgart.
The names and designations used in this document are trademarks or brands belonging
to the respective owners.
Document: 10666-RM-001 EN - 04-2017
Revision: 63084 [RTA-RTE 6.2.0]
This product described in this document includes software developed by the Apache
Software Foundation (http://www.apache.org/).
2
Copyright
RTA-RTE V6.2.0
Reference Manual
Contents
1 About this Manual
1.1
Who Should Read this Manual? . . . . . . . . . . . . . . . . . . . . .
1.2
Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . .
1.3
Acronyms and Abbreviations . . . . . . . . . . . . . . . . . . . . . .
2 Invocation
2.1
Command-line Usage . . . . . .
2.2
Output Files . . . . . . . . . . . .
2.3
OS Configuration File . . . . . .
2.4
COM OIL File . . . . . . . . . . .
2.5
RTE Configuration Constants . .
2.6
Screen Output . . . . . . . . . .
2.7
Error and Information Messages
2.8
Exit Codes . . . . . . . . . . . .
2.9
RTE Library . . . . . . . . . . . .
2.10
User Configuration File . . . . . .
8
8
9
9
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
11
14
14
15
17
18
18
19
19
3 Command-line options
3.1
Examples . . . . . . . . . . . . . . . . . . . . . . . .
3.2
Interaction with ECUC configuration . . . . . . . . .
3.3
-- . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4
--append-name-to-buffer . . . . . . . . . . . . . .
3.5
--atomic-assign . . . . . . . . . . . . . . . . . . .
3.6
--bit-pack-type . . . . . . . . . . . . . . . . . . .
3.7
--bsw . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8
--bsw-scope-limit-defns . . . . . . . . . . . . . .
3.9
--bsw-xml-namespace . . . . . . . . . . . . . . . .
3.10
--calibration-disable . . . . . . . . . . . . . . .
3.11
--calibration-instantiation . . . . . . . . . . .
3.12
--calibration-method . . . . . . . . . . . . . . . .
3.13
--client-server-global-optimization . . . . .
3.14
--com-symbolic-sigs . . . . . . . . . . . . . . . .
3.15
--com-version . . . . . . . . . . . . . . . . . . . . .
3.16
--contract . . . . . . . . . . . . . . . . . . . . . . .
3.17
--deviate-allow-unmapped-swci-config . . . . .
3.18
--deviate-appl-impl-compu-method . . . . . . .
3.19
--deviate-appl-impl-display-format . . . . . .
3.20
--deviate-bsw-any-partition . . . . . . . . . . .
3.21
--deviate-allow-supportsmulti-sharedmemorys
3.22
--deviate-enum-cast . . . . . . . . . . . . . . . .
3.23
--deviate-group-calibration-none . . . . . . .
3.24
--deviate-ignore-datatype-semantics . . . . .
3.25
--deviate-implicit-cat2-mdd . . . . . . . . . . .
3.26
--deviate-implicit-modify-for-loopbacks . . .
3.27
--deviate-memmap-decls . . . . . . . . . . . . . .
3.28
--deviate-omit-implicit-cds . . . . . . . . . . .
3.29
--deviate-physical-dimension-compatibility .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
20
20
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Contents
3
RTA-RTE V6.2.0
Reference Manual
3.30
3.31
3.32
3.33
3.34
3.35
3.36
3.37
3.38
3.39
3.40
3.41
3.42
3.43
3.44
3.45
3.46
3.47
3.48
3.49
3.50
3.51
3.52
3.53
3.54
3.55
3.56
3.57
3.58
3.59
3.60
3.61
3.62
3.63
3.64
3.65
3.66
3.67
3.68
3.69
3.70
3.71
3.72
3.73
3.74
3.75
3.76
3.77
4
--deviate-prefer-no-empty-executions . . .
--deviate-split-swci-support . . . . . . . .
--deviate-task-sections . . . . . . . . . . . .
--deviate-trace-implicit-api . . . . . . . .
--deviate-unconnected-pmode-behavior . . .
--diagnostic . . . . . . . . . . . . . . . . . . .
--disable-warning . . . . . . . . . . . . . . . .
--error-as-warning . . . . . . . . . . . . . . .
--error-report . . . . . . . . . . . . . . . . . .
--exclusive-area-optimization . . . . . . . .
--fast-init . . . . . . . . . . . . . . . . . . . .
--file . . . . . . . . . . . . . . . . . . . . . . .
--force-basic-tasks . . . . . . . . . . . . . .
--have-64bit-int-types . . . . . . . . . . . .
--help . . . . . . . . . . . . . . . . . . . . . . .
--implicit-allocation-method . . . . . . . .
--implicit-read-return-const . . . . . . . .
--implicit-use-global-buffers . . . . . . . .
--incremental-build . . . . . . . . . . . . . .
--initial-value-rounding . . . . . . . . . . .
--ioc-header . . . . . . . . . . . . . . . . . . .
--ioc-xml-namespace . . . . . . . . . . . . . .
--local-mcsd . . . . . . . . . . . . . . . . . . .
--makedep . . . . . . . . . . . . . . . . . . . . .
--mcore-spinlocks-always . . . . . . . . . . .
--mcsd-policy . . . . . . . . . . . . . . . . . . .
--measurement . . . . . . . . . . . . . . . . . . .
--memory-sections . . . . . . . . . . . . . . . .
--notimestamps . . . . . . . . . . . . . . . . . .
--operating-system . . . . . . . . . . . . . . .
--optimize . . . . . . . . . . . . . . . . . . . . .
--os-define-osenv . . . . . . . . . . . . . . . .
--os-fp . . . . . . . . . . . . . . . . . . . . . . .
--os-header . . . . . . . . . . . . . . . . . . . .
--os-output-param . . . . . . . . . . . . . . . .
--os-permit-extended-tasks . . . . . . . . . .
--os-task-as-function . . . . . . . . . . . . .
--os-xml-namespace . . . . . . . . . . . . . . .
--output . . . . . . . . . . . . . . . . . . . . . .
--period . . . . . . . . . . . . . . . . . . . . . .
--preferred-intra-core-protection-scheme
--protection-threshold-copy-bytes . . . . .
--quiet . . . . . . . . . . . . . . . . . . . . . . .
--report . . . . . . . . . . . . . . . . . . . . . .
--rte . . . . . . . . . . . . . . . . . . . . . . . .
--samples . . . . . . . . . . . . . . . . . . . . .
--strict-config-check . . . . . . . . . . . . .
--strict-initial-values-check . . . . . . . .
Contents
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
RTA-RTE V6.2.0
Reference Manual
--strict-unconnected-rport-check
--sws . . . . . . . . . . . . . . . . . . .
--task-recurrence . . . . . . . . . . .
--template-path . . . . . . . . . . . .
--test-license . . . . . . . . . . . . .
--text-value-spec-policy . . . . . .
--toolchain-significant-len . . . .
--use-partition-sections . . . . . .
--variability-also-bind . . . . . . .
--version . . . . . . . . . . . . . . . .
--vfb-trace . . . . . . . . . . . . . . .
--warn-directive . . . . . . . . . . .
--warning-as-error . . . . . . . . . .
--xmlentity . . . . . . . . . . . . . . .
--xmlschema . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
4 Configuration
4.1
XML Namespaces . . . . . . . . . . . .
4.2
References . . . . . . . . . . . . . . . .
4.3
Packages . . . . . . . . . . . . . . . . .
4.4
Software Components . . . . . . . . . .
4.5
AUTOSAR Types and Data Conversion .
4.6
Interfaces . . . . . . . . . . . . . . . . .
4.7
Measurement . . . . . . . . . . . . . . .
4.8
NVRAM . . . . . . . . . . . . . . . . . .
4.9
AUTOSAR Modes . . . . . . . . . . . . .
4.10
Internal Behavior . . . . . . . . . . . . .
4.11
Implementation . . . . . . . . . . . . .
4.12
Signals . . . . . . . . . . . . . . . . . .
4.13
System Signal Group . . . . . . . . . . .
4.14
PDU Type . . . . . . . . . . . . . . . . .
4.15
ECU Types . . . . . . . . . . . . . . . .
4.16
Composition . . . . . . . . . . . . . . .
4.17
ECU Instances . . . . . . . . . . . . . .
4.18
System Description . . . . . . . . . . .
4.19
ECU Description . . . . . . . . . . . . .
4.20
Vendor Specific XML Extensions . . . .
4.21
Post-build . . . . . . . . . . . . . . . . .
4.22
Variability . . . . . . . . . . . . . . . . .
4.23
Support for the atpSplitable Stereotype
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
112
112
115
117
118
131
145
149
153
158
158
177
178
179
179
180
180
182
184
193
201
201
202
209
3.78
3.79
3.80
3.81
3.82
3.83
3.84
3.85
3.86
3.87
3.88
3.89
3.90
3.91
3.92
5 RTE Conventions
212
5.1
Name Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
5.2
Software-Component Naming . . . . . . . . . . . . . . . . . . . . . 212
6 RTE API Reference
213
6.1
API Parameter Passing . . . . . . . . . . . . . . . . . . . . . . . . . . 213
6.2
Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
6.3
Rte_Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Contents
5
RTA-RTE V6.2.0
Reference Manual
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
6.13
6.14
6.15
6.16
6.17
6.18
6.19
6.20
6.21
6.22
6.23
6.24
6.25
6.26
6.27
6.28
6.29
6.30
6.31
6.32
6.33
6.34
6.35
6.36
6.37
6.38
Rte_Prm . . . . . . . . . . . . .
Rte_CData . . . . . . . . . . .
Rte_Enter . . . . . . . . . . . .
Rte_Exit . . . . . . . . . . . . .
Rte_IFeedback . . . . . . . . .
Rte_Feedback / Rte_SwitchAck
Rte_IInvalidate . . . . . . . . .
Rte_Invalidate . . . . . . . . .
Rte_IRead . . . . . . . . . . . .
Rte_IWrite . . . . . . . . . . . .
Rte_IWriteRef . . . . . . . . . .
Rte_IrvIRead . . . . . . . . . .
Rte_IrvIWrite . . . . . . . . . .
Rte_IrvRead . . . . . . . . . . .
Rte_IrvWrite . . . . . . . . . .
Rte_IStatus . . . . . . . . . . .
Rte_IsUpdated . . . . . . . . .
Rte_MainFunction . . . . . . .
Rte_Mode . . . . . . . . . . . .
Rte_Ports . . . . . . . . . . . .
Rte_NPorts . . . . . . . . . . .
Rte_Port . . . . . . . . . . . . .
Rte_Pim . . . . . . . . . . . . .
Rte_Read . . . . . . . . . . . .
Rte_DRead . . . . . . . . . . .
Rte_Receive . . . . . . . . . .
Rte_Result . . . . . . . . . . .
Rte_Send . . . . . . . . . . . .
Rte_Start . . . . . . . . . . . .
Rte_Stop . . . . . . . . . . . .
Rte_Switch . . . . . . . . . . .
Rte_Tick_Timeouts . . . . . . .
Rte_Trigger . . . . . . . . . . .
Rte_IrTrigger . . . . . . . . . .
Rte_Write . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
216
217
218
219
220
221
222
223
224
225
225
226
227
228
229
230
230
231
232
233
233
234
235
236
237
238
240
241
242
242
243
244
245
245
246
7 RTE Runnable API Reference
248
7.1
Supported RTE Events . . . . . . . . . . . . . . . . . . . . . . . . . . 248
7.2
Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
7.3
SWC Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
8 VFB Tracing
8.1
Enabling VFB Tracing . . . .
8.2
Trace Events . . . . . . . . .
8.3
Trace Event Implementation
8.4
Optimization . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
251
251
251
254
255
9 Memory Mapping and Compiler Abstraction
256
9.1
Memory Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
6
Contents
RTA-RTE V6.2.0
Reference Manual
9.2
10 External
10.1
10.2
10.3
10.4
10.5
Compiler Abstraction
Dependencies
C Library . . . . .
OS Configuration .
AUTOSAR COM . .
Operating System
Calibration . . . .
.
.
.
.
.
. . . . . . . . . . . . . . . . . . . . . . . . . . 258
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11 Parameters of Implementation
11.1
AUTOSAR Common Published
11.2
API Legitimacy . . . . . . . .
11.3
Tasks and Runnable Entities .
11.4
Queued Communication . . .
11.5
Scheduling . . . . . . . . . .
11.6
Modes and Mode Switches .
11.7
Inter-ECU Communication . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Information
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
260
260
260
263
265
266
.
.
.
.
.
.
.
273
273
273
273
274
274
274
275
12 AUTOSAR Revision Support
276
13 Contact, Support and Problem Reporting
277
Contents
7
RTA-RTE V6.2.0
Reference Manual
1
About this Manual
The manual provides a complete reference to the syntax and semantics of the RTE
configuration language, the operation of the RTA-RTE RTE generation tool, RTEGen, and
the syntax and semantics of the generated RTE interface.
• Chapter 2 describes how to invoke the RTE generator and what output to expect
• Chapter 3 provides a reference of the command-line options of RTA-RTE.
• Chapter 4 provides a reference for the AUTOSAR XML used to configure RTA-RTE.
• Chapter 5 describes the RTA-RTE namespace, software component and API naming
conventions in RTA-RTE.
• Chapter 6 presents a reference to the API as seen by software components. The API
includes calls for sender-receiver and client-server communication, concurrency
control and access to data memory sections.
• Chapter 7 explains how the runnable entities are declared using the RTE API and
provides a reference to the different classes of runnable entity.
• Chapter 8 describes how VFB tracing events are configured and used.
• Chapter 9 explains how elements within the generated RTE can be mapped to different memory segments using the AUTOSAR memory mapping and compiler abstraction.
• Chapter 10 describes the external objects (e.g. OS objects) required by a generated
RTE and defines the APIs provided by external AUTOSAR modules that are used by
the generated RTE.
• Chapter 11 defines limits and constraints imposed by RTA-RTE on the generated
RTE.
1.1
Who Should Read this Manual?
The RTA-RTE Reference Manual is intended for the software engineer who understands
the concepts and general techniques of developing an RTE-based application and needs
to know key technical detail about configuration and implementation.
It is assumed that the reader is familiar with the RTA-RTE User Guide.
1.1.1
Related Documents
This document is intended to be read in conjunction with the RTA-RTE User Guide.
This document also references information contained in the AUTOSAR Software Specifications, in particular AUTOSAR Specification of RTE.
8
About this Manual
RTA-RTE V6.2.0
Reference Manual
1.2
Document Conventions
Notes that appear like this contain important information that you need to
be aware of. Make sure that you read them carefully and that you follow any
instructions that you are given.
Notes that appear like this describe things that you will need to know if you
want to write code that will work on any target processor.
In this guide you’ll see that program code, header file names, C type names, C functions
and API call names all appear in the courier typeface. When the name of an object
is made available to the programmer the name also appears in the courier typeface,
suitably modified in accordance with the RTE naming conventions. So, for example, a
runnable called Runnable1 appears as a handle called Runnable1.
1.3
Acronyms and Abbreviations
AUTOSAR
AUTomotive Open System ARchitecture - a standardized
software architecture targeted at automotive applications
aimed at fostering the reuse of application software over
multiple vehicle platforms.
BNF
Backus-Naur Form; a notation used to describe language
grammars.
ECUC
AUTOSAR ECU Configuration
MISRA
Motor Industry Software Reliability Association
RTA-OSEK
An AUTOSAR SC1 and OSEK 2.2.3 compatible operating
system from ETAS GmbH.
RTE
AUTOSAR Run-Time Environment. See “Introduction to the
RTE” in the RTA-RTE User Guide.
RTA-RTE
The ETAS AUTOSAR RTE Generator Product. This includes
the AUTOSAR RTE Generator Tool responsible for reading
the AUTOSAR XML configuration and generating the RTE
and associated C header files. RTA-RTE distributions also
include the RTE library, all user documentation and an example application.
XML
eXtensible Markup Language used to describe AUTOSAR
configurations.
RTEGen
The ETAS AUTOSAR RTE generator tool responsible for
reading the AUTOSAR XML configuration and generating
the RTE and associated C header files.
About this Manual
9
RTA-RTE V6.2.0
Reference Manual
URI
10
Uniform Resource Identifier – a character string that identifies (names) a resource. Within XML a URI identifies a
namespace.
About this Manual
RTA-RTE V6.2.0
Reference Manual
2
Invocation
The RTA-RTE RTE generator is a Win32 executable that provides multiple functions:
• Generation of a “contract” API for use by software components during development.
• Generation of an optimized production RTE for a specific target ECU.
• Optional creation of an OS configuration for RTE created OS objects.
• Optional creation of a COM OIL configuration for RTE created COM objects.
Each core function forms an execution phase. The two “contract” and “RTE” phases
are typically widely separated in time with the “contract” phase occurring before development of a component starts and the “RTE” phase after component deployment is
complete.
RTEGen takes one or more XML-based configuration files as input. The structure of these
files is defined in Chapter 5.
2.1
Command-line Usage
The RTE generator is invoked from the command line as follows:
RTEGen [options] <input files>
Command line options can be specified using either short or long (GNU style) names –
the supported options are listed below.
Any number of XML input files can be specified.
When a command line option takes an argument, the argument can be specified either
as a trailing word or with an equals sign. For example, given an option opt with argument arg the option could be specified as either “--opt arg” or “--opt=arg”. The two
forms are equivalent and can be mixed on the command line.
The ordering of command line parameters is unimportant: options and XML files can
be mixed freely. Command line options are read left-to-right and are processed before
any input files are read.
See Chapter 3 for a reference to all RTA-RTE command-line options.
2.2
Output Files
Each execution of the RTE generator in RTE-generation phase creates output for a single ECU instance. In contract phase, files are generated for each application-software
component specified on the command line.
Table 2.1 describes the output files generated by the RTE generator in RTE-generation
and contract phases.
Invocation
11
RTA-RTE V6.2.0
Reference Manual
File
Description
Rte.h
Core RTE header file.
Rte_Intl.h
Rte_Main.h
Rte_Lib.c
Rte.c
3
3
Private RTE declarations and
definitions.
3
3
RTE lifecycle API declarations.
3
3
7
3
7
3
7
3
7
3
7
3
3
3
3
3
The RTE library.
The RTE source file.
Rte_Cbk.h
Rte_Const.h
Rte_Hook.h
Rte_Type.h
Rte_<SWC>.h
12
Contract? RTE?
Invocation
C header file containing prototypes for all call-back functions created within the generated RTE.
A C header file containing
RTE configuration constants.
See Section 2.5.
VFB trace hook definitions
C header file containing definitions of the types described in the input file. This
file is automatically included
by other generated files.
A C header file containing the RTE API customized
for each software component specified in the input
file. This file is the component’s application header
file.
RTA-RTE V6.2.0
Reference Manual
File
Description
<TaskName>.c
(Vendor mode
only)
A C source file containing a
single OSEK task for each
<TaskName> defined in the
configuration file. In compatibility mode task bodes are
created within the generated
RTE file.
Contract? RTE?
Rte_BSWMD.arxml AUTOSAR XML file describing the features of the generated RTE code. Note that the
McSupportData is written to
a separate file following the
AUTOSAR splittable pattern.
Rte_McSupportData.arxml
AUTOSAR XML file containing the McSupportData, that
is, information need to generate A2L files for measurement/calibration tools. This
can be regarded as an excerpt from the BSW Module
Description and indeed can
be merged into it following
the AUTOSAR splittable pattern.
Rte_Catalog.xml An XML file containing the
actual filenames used in the
RTE output.
7
3
3
3
7
3
3
3
Table 2.1: Generated Output Files
The following files are optional – whether or not they are generated depends on the
configuration of the RTE generator.
File
Description
Rte.err
RTE error file (see –err option).
OS configuration
COM
tion
configura-
An XML/OIL configuration file
for the AUTOSAR/OSEK Operating System.
An OIL/configuration file for
AUTOSAR COM R1.0.
Contract? RTE?
3
3
7
3
7
3
Invocation
13
RTA-RTE V6.2.0
Reference Manual
Table 2.2: Optional Output Files
2.2.1
Redirecting Output
By default all output files are generated in the current directory – this is typically the
same directory as the input file. The --output option can be used to direct specific
output files to a defined folder.
For example, the RTA-RTE RTE generator can be directed to write all generated C files
to folder abc using the following option:
--output="[*.c]abc"
The pattern specified using the -o option does not need to include a wild card. The
following option directs only the generated RTE to folder abc:
--output "[Rte.c]abc"
The --output option can be specified multiple times on the command-line. Options
are processed left-to-right and therefore different patterns for output redirection are
also processed left-to-right. For example, to redirect Rte_Type.h to one folder and all
other generated header files to another folder one could use one must specify the more
general pattern last:
--output "[Rte_Type.h]folder1" --output "[*.h]folder2"
2.3
OS Configuration File
RTA-RTE can optionally generate an OS configuration file1 that defines all OS objects
used by the generated RTE.
The generated OS configuration file does not contain any target specific information –
only target-neutral OS objects are defined. Therefore the file should be combined with
an additional OS configuration file that defines target information (e.g. OS status, hook
usage, ISRs, etc.). Depending on the OS, the additional OS configuration could reference the generated OS configuration file using a “#include” mechanism (RTA-OSEK and
generic OSEK), auxiliary OIL files (RTA-OSEK only) or by merging XML files (RTA-OS3.0).
Generation of the OS configuration requires system information and therefore it is created during RTE phase only.
See Section 10.2 for details of the OS objects created within the OS configuration file.
2.4
COM OIL File
RTA-RTE can optionally generate a AUTOSAR COM R1.0 configuration file, rta-com.oil.
This file defines all COM objects (messages and I-PDUs) used by the generated RTE.
1
The filename depends on the selected OS plug-in. The default filename used by the RTA-OSEK plug-in
is rta-osek.oil.
14
Invocation
RTA-RTE V6.2.0
Reference Manual
As with the generated OS configuration, the COM configuration does not contain any
target specific information – only target-neutral COM objects are defined. Therefore
the file should be used with a “wrapper” OIL file that defines target information (COM
status, timebase etc.) and the references the generated OIL file using the “#include”
mechanism.
Generation of the COM configuration requires information on how software components
communicate and therefore it is created during RTE phase only.
Support for generating a COM configuration file is not included in all versions
of RTA-RTE.
2.5
RTE Configuration Constants
During RTE phase, RTA-RTE creates the file Rte_Const.h. This file defines constants
derived from the configuration that are used to optimize the compilation of the RTE
library.
2.5.1
C Library
By default, RTA-RTE is independent of the C library and uses the RTE library function
Rte_memcpy when copying memory.
Alternatively, RTA-RTE will use the standard C Library memcpy function if the symbol
RTE_LIBC_MEMCPY is defined when compiling the RTE library and RTE generated code.
Use of the standard function from the C library may be preferred if, for example, the
target compiler supports a built-in function that compiles to inline optimal assembler.
The RTE_LIBC_MEMCPY symbol can either be placed within the user configuration file
(see Section 2.10) or on the command-line when compiling the RTE library and RTE
generated code, for example:
... -DRTE_LIBC_MEMCPY
2.5.2
2.5.3
Calibration Method
Constant
Description
RTE_CALPRM_SINGLE_PTR
Defined if the selected global calibration method is “single”.
RTE_CALPRM_DOUBLE_PTR
Defined if the selected global calibration method is “double”.
RTE_CALPRM_INITRAM
Defined if the selected global calibration method is “initram”.
RTE_CALPRM_NONE
Defined if the selected global calibration method is “none”.
Measurement
Invocation
15
RTA-RTE V6.2.0
Reference Manual
2.5.4
Constant
Description
RTE_MEASUREMENT_SUPPORT
Defined as “1” if measurement is
enabled in the RTE module configuration and “0” otherwise.
Counters
The generated OS configuration uses two counters, Rte_Tick_Counter for periodic activities (schedule table or periodic alarms) and Rte_Tout_Counter for sporadic alarms
(timeouts, etc.). The tick rate for the counters is defined in Rte_Const.h.
Constant
Description
RTE_PERIODIC_COUNTER_TICK_INTERVAL_US
The tick interval (in microseconds)
of the counter used to drive the
generated RTE’s Schedule Table or
periodic alarms.
RTE_ALARM_COUNTER_TICK_INTERVAL_US
The tick interval (in microseconds)
of the counter used to drive the
generated RTE’s timeout alarms.
Not defined if no timeout alarm is
required.
The counters are not ticked directly by user code but instead calls the generated API
Rte_Tick_Timeouts at the counter’s tick rate. (see Section 6.35).
Main Function
The period of the RTE’s main function defaults to 10ms but can also be set explicitly on
the command-line. The invocation rate in milliseconds is defined in Rte_Const.h.
2.5.5
Constant
Description
RTE_MAINFUNCTION_PERIOD_US
The tick interval (in microseconds)
of RTE’s main function.
Invocation of the RTE’s main
function is only required when
runnable entity minimum start intervals (see Section 4.10.10) are
used.
OS Integration
The Rte_Const.h file includes constants that define the OS API and OS configuration
format in use.
16
Invocation
RTA-RTE V6.2.0
Reference Manual
Constant
Description
RTE_OSAPI_AUTOSAR_R10
Defined if an AUTOSAR R1.0 compatible OS API is being used.
RTE_OSAPI_AUTOSAR_R30
Defined if an AUTOSAR R3.0 compatible OS API is being used.
RTE_OSAPI_OSEK
Defined if an OSEK compatible OS
API is being used.
RTE_OSAPI_ERCOSEK
Defined if an ERCOSek compatible
OS API is being used.
RTE_OSCFG_RTAOSEK
Defined if RTA-OSEK OS configuration file fragment is being used.
RTE_WOWP_EVENTS
Number of RTE defined events
used within RTE generated code
for handling timeouts and RTE activity.
RTE_OS_EVENTS
Number of OS events in use for
runnable activation.
RTE_NULL_SCHEDULE
Defined if no periodic runnable entities exist.
The generated constants can be used to adapt application code to varying configurations. For example, an ISR activated every millisecond can be written to automatically
tick the RTE’s counter at the correct rate irrespective of the configured TimingEvents
as follows:
#define DELAY_FACTOR (RTE_PERIODIC_COUNTER_TICK_INTERVAL_US / \
US_PER_TICK )
static uint16 count = DELAY_FACTOR;
ISR(my1msISR)
{
if ( --count == 0 )
{
Rte_Tick_Timeouts();
count = DELAY_FACTOR;
}
}
2.6
Screen Output
All screen output appears on the standard output. The RTA-RTE RTE generator will
output the phase of generation followed by a log of operations performed. For example:
c:\rte_projects>\RTEGen --c /MyPkg/MySWC MyFile.xml
Invocation
17
RTA-RTE V6.2.0
Reference Manual
RTA-RTE v4.0.0
Copyright (C) ETAS GmbH 2004-2011
Loading MyFile.xml... done
URI: http://autosar.org/schema/r4.0
Phase is Contract (license verified, permanent)
Validating DOM... done
Building types database... done
Building reification tree... done
Generating intermediate XML... done
Generating RTE C... done
Generation complete
The following files were generated:
Rte_MySWC.h
Rte_Type.h
2.7
Error and Information Messages
The RTA-RTE RTE generator presents information on the progress of RTE generation
using a system of status messages. Messages have the following classification:
Fatal – the detected error prevents further processing and the RTE generator terminates immediately. No RTE or associated files are generated.
Error – the detected error is serious but does not prevent further processing. No RTE
or associated files are generated.
Warning – the detected error does not prevent further processing. The RTE and associated files will be generated but should not be considered to be correct until the
source of the warning has been investigated.
Information – a status message that does not indicate an error.
2.8
Exit Codes
In addition to progress and error messages, the RTA-RTE RTE generator returns the
following error codes that can be used to confirm the success or otherwise of RTE generation:
• 0 : Success – the application headers (RTE and contract phase) or other files (RTE
phase only) were generated without error.
• 1 : Failure – the input configuration was found to be invalid or generation failed for
an environmental reason such as the output location not being writable.
• Other: Unexpected internal failure of the generator.
18
Invocation
RTA-RTE V6.2.0
Reference Manual
2.9
RTE Library
In addition to the generated Rte.c, RTA-RTE generates library code in Rte_Lib.c that
must be compiled and linked along with the generated code and the application code
to form the final executable.
The location to which Rte_Lib.c is generated can be altered using the --output
command-line option.
RTA-RTE optimizes the Rte_Lib.c when it is generated and also through preprocessor
constants (Section 2.5) defined in Rte_Const.h.
The RTE library must be recompiled each time the input configuration
changes.
It is forbidden to call functions found in Rte_Lib.c except where documented in Chapter 6.
2.10
User Configuration File
RTA-RTE includes use of an optional user configuration file Rte_UserCfg.h that can be
used to modify how the generated RTE and the RTE library are compiled.
RTA-RTE includes a default Rte_UserCfg.h and therefore it is only necessary
to define a custom file to define different definitions.
The following constants can be defined in Rte_UserCfg.h to modify how the generated
RTE and the RTE library are compiled.
Definition
Notes
RTE_LIBC_MEMCPY
When defined the use of the RTE library
function Rte_memcpy is replaced by the
standard C library function memcpy.
For definitions within a custom user configuration file to have any effect the
compiler’s include path must be set so that the new user configutation file
is read before the default file.
Invocation
19
RTA-RTE V6.2.0
Reference Manual
3
Command-line options
The operation of the RTE generator is controlled via command-line options. All options
begin with either the ‘-’ or ‘@’ characters; any other parameter on the command-line
is interpreted as an input filename.
Parameters (i.e. filenames) specified either on the command-line or in sub-files that
contain spaces must be quoted according to the rules of the invoking environment,
e.g.:
RTEGen [options] "input filename.xml"
3.1
Examples
To display the RTA-RTE product and RTE generator versions using long-form option
names:
RTEGen --version
To generate the contract for a software component ‘swcA’ in package ‘pkgB’ using short
option names:
RTEGen --contract=/pkgB/swcA input.xml
To generate the RTE for the ECU instance referenced from ECU configuration ecuConfig
in package ‘pkgC’ using short option names:
RTEGen --rte=/pkgC/ecuConfig ...
To generate the RTE using commands from subfile MyCommandLine while suppressing
all informational messages:
RTEGen --quiet=3 --file MyCommandLine
To use the ‘#warning’ pre-processor directive when issuing a warning within generated
C code instead of the default ‘#pragma message’:
RTEGen --warn=warning ...
3.2
Interaction with ECUC configuration
AUTOSAR defines certain configuration settings within the RteGeneration container
that can also be specified on the RTA-RTE command-line:
20
ECUC Parameter
RTA-RTE Command-line option
RteOptimizationMode
--optimize
RteCalibrationSupport
--calibration-method
RteVfbTraceEnabled
--vfb-trace
Command-line options
RTA-RTE V6.2.0
Reference Manual
ECUC Parameter
RTA-RTE Command-line option
RteMeasurementSupport
--measurement
RteToolChainSignificantCharacters
--toolchain-significant-len
For RTE generation phase, the option can be set either in the ECUC file or on the
command-line. If specified in both places then RTA-RTE will use the command-line value
– this enables simple override of the “fixed” configuration value.
For Contract phase, RTA-RTE does not read the ECUC generation container and therefore the options can only be specified on the command-line.
Command-line options
21
RTA-RTE V6.2.0
Reference Manual
3.3
-Description:
End of options
Name:
-Parameter:
(None)
Default:
(None)
Notes:
Indicates the end of options list. All tokens on the command line
after this option are treated as filenames.
This option is required when one or more filenames start with “--”.
Example:
RTEGen.exe --rte=auto -- --model--file--name--with--dashes.arxml
22
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.4
--append-name-to-buffer
Description:
Append name to buffer symbol.
Name:
--append-name-to-buffer
Parameter:
This option takes a single parameter that specifies whether to include (‘1’) or exclude (‘0’) the name from the created receive buffer
name.
Default:
0
Notes:
When RTA-RTE creates buffers to handle receive data or store measurable data, it names them using incrementing integers to keep
identifier lengths within the limits specified by AUTOSAR and MISRA.
When this option is enabled, RTA-RTE appends the data element or
operation argument name to the standard buffer name to make the
generated code easier to read, with the risk that the identifiers become too long for some compilers or static checkers.
Example:
To cause RTA-RTE to append the data element name to the generated buffers:
--append-name-to-buffer=1
When this option is enabled, RTA-RTE creates receive buffers with
names of the form Rte_Rx_000000_<name>.
Command-line options
23
RTA-RTE V6.2.0
Reference Manual
3.5
--atomic-assign
Description:
Specify the SwBaseTypes that are assigned atomically on your target
platform.
Name:
--atomic-assign
Parameter:
This option takes a comma-separated list of SwBaseType shortNames
that describe types that do not need concurrency protection (e.g.
RTE_ATOMIC16()).
Default:
All assigments are regarded as potentially in need of protection
against read-modify-write errors.
Notes:
This option must be used with care: if applied to a type that is not
atomic on your target platform, subtle run-time errors may occur
that will be hard to track and eliminate.
Note that this option affects SwBaseTypes with the given shortName(s). It does not attempt to match SwBaseTypes with a different shortName, even if the size and alignment are the same. (RTARTE does not know how, for example, nativeDeclaration might affect
atomicity).
Example:
To suppress concurrency protection on 16- and 8-bit AUTOSAR Platform types, the following is sufficent:
--atomic-assign=uint16,uint8,sint16,sint8
24
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.6
--bit-pack-type
Description:
Specify underlying ImplementationDataType for bit-packed flags.
Name:
--bit-pack-type
Parameter:
This option takes a single parameter which is a reference to the
ImplementationDataType to use to contain bitfields.
Default:
/AUTOSAR_PlatformTypes/ImplementationDataTypes/uint16
Notes:
None.
Example:
To use the uint32 platform type for holding bit-packed flag in generated code, use the following command:
--bit-pack-type=/AUTOSAR_PlatformTypes/ImplementationDataTypes/uint16
Command-line options
25
RTA-RTE V6.2.0
Reference Manual
3.7
--bsw
Description:
Select “BSW” generation phase to generate the BSW Scheduler components only.
Name:
--bsw
Parameter:
This option takes a single parameter, that specifies either the ECU
instance or the ECU configuration for which BSW generation should
occur.
Default:
N/A
Notes:
The ECU instance <ECUI> must be specified using an absolute instance reference. (See Section 4.2.4.)
It is an error if the input XML contains any SWC configuration data.
Example:
To select BSW generation phase for ECU configuration /pkg/ecu use
the following command:
--bsw=/pkg/ecu
26
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.8
--bsw-scope-limit-defns
Description:
Control use of scope-limiting definitions for BSW.
Name:
--bsw-scope-limit-defns
Parameter:
This option takes a single parameter, <P>, that determines whether
scope-limiting definitions are generated for BSW APIs within the
Module Interlink Header file. Generation is not required for AUTOSAR
compliance.
Default:
If this option is not specified scope limiting definitions are generated
in the same form as used for application header files.
Notes:
This option is supported by the OutputC plug-in.
Example:
To use enable generation of scope-limiting definitions, use:
--bsw-scope-limit-defns=on
Command-line options
27
RTA-RTE V6.2.0
Reference Manual
3.9
--bsw-xml-namespace
Description:
Set the XML namespace URI used in generated BSW configuration
file.
Name:
--bsw-xml-namespace
Parameter:
This option takes a single parameter, <URI>, that specifies the
namespace URI to be used within the generated BSW configuration
file.
Default:
If this option is not specified the default namespace is used.
Notes:
This option is supported by the RTA-BSW plug-in.
Example:
To use http://namespace as the namespace URI when generating
the BSW configuration file, use:
--bsw-xml-namespace=http://namespace
28
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.10
--calibration-disable
Description:
Disable RTE calibration supported for specified SWC type.
Name:
--calibration-disable
Parameter:
This option takes a single parameter, <SWC>, which must be an absolute reference to the SWC type for which calibration should be
disabled.
Default:
N/A
Notes:
This option has no effect if the selected global calibration method
is ‘none’. Calibration can also be disabled for individual SWC types
using the ECU Configuration description.
Example:
To disable calibration for SWC /pkg/swcA use the following command:
--calibration-disable=/pkg/swcA
Command-line options
29
RTA-RTE V6.2.0
Reference Manual
3.11
--calibration-instantiation
Description:
Determines whether RTA-RTE allocates memory (RAM) for calibration
instances or imports labels.
Name:
--calibration-instantiation
Parameter:
This option takes a single parameter, that specifies whether to
import (import) or allocate memory (‘allocate’) for calibration
instances.
Default:
allocate.
Notes:
None.
Example:
The command-line option:
--calibration-instantiation=allocate
Causes RTA-RTE to allocate RAM buffers for each calibration group.
These buffers should be initialized by the application before the RTE
is started. (See section ??.)
Alternatively, the command-line option:
--calibration-instantiation=import
Causes RTA-RTE only to import labels using the extern keyword.
These labels can be set to buffers which are initialized externally
to the generated RTE code.
30
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.12
--calibration-method
Description:
Select the global calibration method.
Name:
--calibration-method
Parameter:
This option takes a single parameter that specifies the selected calibration method. Supported values are: none, singlePointered
doublePointered, initializedRam, and singlePointered2
Default:
none
Notes:
The selected calibration method affects the data structures and generated functions created to support calibration. The API presented
to SW-Cs within the application header is not affected.
For RTE generation phase, this option can be set both in the ECUC file
and on the command-line. If specified in both places then RTA-RTE
will use the command-line value.
Example:
To select single-pointered method:
--calibration-method=singlePointered
Command-line options
31
RTA-RTE V6.2.0
Reference Manual
3.13
--client-server-global-optimization
Description:
Select whether or not non-AUTOSAR optimizations of inter-partition
client-server communication should be performed.
Name:
--client-server-global-optimization
Parameter:
This option takes a single parameter which enables (“on” or “1”) or
disables (“off” or “0”) use of non-AUTOSAR optimizations for interpartition client-server communication.
Default:
Disabled (“off”) for AUTOSAR compliance.
Notes:
None.
Example:
To enable the use of non-AUTOSAR optimizations for inter-partition
client-server communication:
--client-server-global-optimization=on
32
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.14
--com-symbolic-sigs
Description:
Use C symbols for COM signal handles.
Name:
--com-symbolic-sigs
Parameter:
None.
Default:
By default, RTA-RTE generates an RTE that uses a COM signal’s numerical handle ID when invoking COM API functions.
Notes:
When this option is specified the generated RTE uses the symbolic
name of the signal instead of the handle ID. This option must be
specified when RTA-RTE is used with an AUTOSAR v1.0 compliant
COM.
Example:
To enable use of symbolic signal names:
--com-symbolic-sigs
Command-line options
33
RTA-RTE V6.2.0
Reference Manual
3.15
--com-version
Description:
Modify the generated code to be appropriate for the given version of
AUTOSAR COM.
Name:
--com-version
Parameter:
The parameter <V> specifies the required version. Supported and
default COM versions are dependent on the selected RTA-RTE backend processor.
Default:
Dependent on selected backend processor.
Notes:
None.
Example:
To specify use of AUTOSAR COM v1.0:
--com-version=1.0
34
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.16
--contract
Description:
Execute contract phase for a specific software module.
Name:
--contract
Parameter:
This option takes a single parameter that must be an absolute reference to the ApplicationSoftwareComponentType type or BswImplementation for which contract-phase headers should be generated.
Default:
N/A
Notes:
Use --contract to support the AUTOSAR RTE Contract Phase or Basic Software Scheduler Contract Phase. RTA-RTE will generate an
application header file for the specified application software component type or BSW implementation. To generate headers for multiple
software modules, the --contract option can be repeated on the
command line. You cannot mix contract phase and generation phase
in the same run of RTA-RTE.
Example:
To generate the contract phase headers for two hypothetical Software Component Types swcA and swcB:
--contract=/myPackage/ApplicationSwComponentTypes/componentA --contrac
Command-line options
35
RTA-RTE V6.2.0
Reference Manual
3.17
--deviate-allow-unmapped-swci-config
Description:
Enable SWC instances within the RTE module configuration to be
mapped to a different ECU instance.
Name:
--deviate-allow-unmapped-swci-config
Parameter:
This option permits (“1”) or forbids (“0”) SWC instances within the
RTE module configuration to be mapped to a different ECU instance.
When permitted a warning will be issued for each unmapped instance but generation will continue.
Default:
Forbid (“0”).
Notes:
None.
Example:
To allow unmapped SWC instances:
--deviate-allow-unmapped-swci-config=1
36
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.18
--deviate-appl-impl-compu-method
Description:
This option suppresses the error that would be generated by having
a CompuMethod on both an Application Data Type and its mapped
Implementation Data Type.
Name:
--deviate-appl-impl-compu-method
Parameter:
This option enables (“1”) or disables (“0”) the deviation.
Default:
Enabled (“1”).
Notes:
Standard AUTOSAR behavior specifies that when the CompuMethod
is in both an Implementation Data Type and its mapped Application
Data Type that this is an error.
Example:
To make RTA-RTE raise a configuration error when the CompuMethod
is on both the Application Data Type and its mapped Implementation
Data Type (which is standard AUTOSAR behavior):
--deviate-appl-impl-compu-method=off
Command-line options
37
RTA-RTE V6.2.0
Reference Manual
3.19
--deviate-appl-impl-display-format
Description:
This option suppresses the error that would be generated by having
a DisplayFormat on both an Application Data Type and its mapped
Implementation Data Type.
Name:
--deviate-appl-impl-display-format
Parameter:
This option enables (“on” or “1”) or disables (“off” or “0”) the
deviation.
Default:
Enabled (“on”).
Notes:
Standard AUTOSAR behavior specifies that when the DisplayFormat
is in both an Implementation Data Type and its mapped Application
Data Type that this is an error.
Example:
To make RTA-RTE raise a configuration error when the DisplayFormat
is on both the Application Data Type and its mapped Implementation
Data Type (which standard AUTOSAR behavior)
--deviate-appl-impl-display-format=off
38
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.20
--deviate-bsw-any-partition
Description:
Enable mapping of BSW to any OS partition.
Name:
--deviate-bsw-any-partition
Parameter:
This option enables (“1”) or disables (“0”) an RTA-RTE deviation from
the AUTOSAR RTE specification. When enabled BSW may be mapped
to any OS partition.
Default:
Disabled (“0”).
Notes:
None.
Example:
To enable mapping of BSW to any partition:
--deviate-bsw-any-partition=1
This option has received limited testing in this release of
RTA-RTE. If mapping to any partition is enabled the generated RTE must be thoroughly tested before use.
Command-line options
39
RTA-RTE V6.2.0
Reference Manual
3.21
--deviate-allow-supportsmulti-sharedmemorys
Description:
Allow supportsMultipleInstantiation to be set on a SWCT with
staticMemorys.
Name:
--deviate-allow-supportsmulti-sharedmemorys
Parameter:
This option enables (“1”) or disables (“0”) an RTA-RTE deviation from
the AUTOSAR RTE specification. According to the specification, it is
an error to set supportsMultipleInstantiation on an InternalBehavior
that contains staticMemorys. When this option is enabled, the error
is reduced to a warning, and an error is only raised if the input model
actually contains multiple instances of the related SWCT.
Default:
Disabled (“0”).
Notes:
None.
Example:
--deviate-allow-supportsmulti-sharedmemorys=1
40
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.22
--deviate-enum-cast
Description:
Explicitly cast literals used in enumerations (AUTOSAR TEXTTABLEs).
Name:
--deviate-enum-cast
Parameter:
This option takes a single parameter, <N>, that specifies whether the
option is enabled (‘1’) or disabled (‘0’).
Default:
Disabled (AUTOSAR compliant).
Notes:
RTA-RTE writes preprocessor define directives for the symbolic values in TEXTTABLEs according to AUTOSAR (rte_sws 3810).
In addition to this, if the --deviate-enum-cast option is enabled,
RTA-RTE also emits an explicit cast to the underlying ImplementationDataType.
Regardless of this option, RTA-RTE writes a ‘U’ suffix to the numeric
literal if the underlying SwBaseType is unsigned or missing.
Example:
#define E1_VALUE1 34U
with --deviate-enum-cast=1 becomes
#define E1_VALUE1 (myUnsignedEnumType)34U
Command-line options
41
RTA-RTE V6.2.0
Reference Manual
3.23
--deviate-group-calibration-none
Description:
Control grouping of calibration parameters.
Name:
--deviate-group-calibration-none
Parameter:
This option takes a single parameter, <N>, that specifies whether to
enable (‘1’) or disable (‘0’) the grouping of calibration parameters for
‘none’ calibration method.
Default:
Disable grouping (AUTOSAR compliant).
Notes:
RTA-RTE instantiates calibration parameters. For the single- and
double-pointered calibration methods all parameters are grouped
according to the assigned SwAddrMethod. This option enables
grouping to also be applied when the ‘none’ calibration method is
selected.
RTA-RTE will apply grouping when no flatmap instance descriptor is
available since the descriptor is required to assign a name to the
parameter instance.
Example:
To cause RTA-RTE to group calibration parameters when using the
‘none’ method:
--deviate-group-calibration-none=1
42
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.24
--deviate-ignore-datatype-semantics
Description:
Control semantic checks when checking type correctness.
Name:
--deviate-ignore-datatype-semantics
Parameter:
This option takes a single parameter, <P>, that specifies whether to
ignore (‘1’) or enable (‘0’) the semantic checking of connected data
types
Default:
Enable check (‘0’).
Notes:
AUTOSAR specifies compatibility rules for connected DataPrototypes
involving the referenced AutosarDataType and any CompuMethods, Units, or PhysicalDimensions involved. Additionally, for R4.x
projects, the AUTOSAR specification states that when VariableDataPrototypes are not compatible it is still permitted to connect them
if they conform to further rules about whether automatic data conversion is possible.
In some configurations, it may be necessary to allow connection of
DataPrototypes that do not fully conform to the AUTOSAR compatibility rules.
With this option specified, the compatibility and convertibility checks
are very much relaxed, with the CompuMethod, Unit, and PhysicalDimension being completely ignored.
In addition, RTA-RTE normally checks that any CompuMethod referenced by an ImplementationDataType is permitted according to constr_1158, raising an error if the check fails. If this option is specified,
then the error is downgraded to a warning, allowing the generation
to continue.
Example:
To ignore semantic checks:
--deviate-ignore-datatype-semantics=1
Command-line options
43
RTA-RTE V6.2.0
Reference Manual
3.25
--deviate-implicit-cat2-mdd
Description:
Enable mode disabling dependency for category 2 runnables.
Name:
--deviate-implicit-cat2-mdd
Parameter:
This option permits (“1”) or forbids (“0”) mode disabling dependency
for implicitly category 2 runnables.
Default:
Forbid (“0”).
Notes:
Prior to AUTOSAR R4.0, a runnable is implicitly category 2 if it includes a synchronous call point. This option permits such runnables
to have mode disabling dependencies.
Example:
To enable mode disabling dependencies for category 2 runnables:
--deviate-implicit-cat2-mdd=1
44
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.26
--deviate-implicit-modify-for-loopbacks
Description:
Enable “data modify” semantics for implicit access to data items
where there is a loopback assembly connector.
Name:
--deviate-implicit-modify-for-loopbacks
Parameter:
This option enables (“on” or “1”) or disables (“off” or “0”) “data modify” semantics for implicit access to data items where a loopback
assembly connector exists.
Default:
Disabled (“off”).
Notes:
Without this option, RTA-RTE implements AUTOSAR rules for the visibility and propagation of implicit data, and creates uninitialized Write
Buffers for implicit writers to support that. One consequence of this
is that Runnables using Rte_IWriteRef to write parts of a complex
type will result in undefined values being propagated on the other
members of the type.
When this option is enabled, if you connect the PPort back to an
RPort characterized by the same interface in the same swc prototype, then RTA-RTE initializes the implicit writeback buffers from the
definitive, global buffer before the Runnable enters. This enables the
use of partial writes of complex data by multiple runnables without
the propagation of undefined variables.
It is permitted, but not necessary, to configure a DataReadAccess in
the Runnable for the configured RPort.
In applications using split
Example:
To enable “data modify” semantics for implicit access to data items:
--deviate-implicit-modify-for-loopbacks=on
Command-line options
45
RTA-RTE V6.2.0
Reference Manual
3.27
--deviate-memmap-decls
Description:
Select whether or not memory allocation sequences should be used
for declarations as well as definitions.
Name:
--deviate-memmap-decls
Parameter:
This option takes a single parameter which enables (“on” or “1”) or
disables (“off” or “0”) use of MemMap for declarations.
Default:
Enabled (“on”).
Notes:
None.
Example:
To disable generation of MemMap decorations:
--deviate-memmap-decls=off
46
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.28
--deviate-omit-implicit-cds
Description:
Enable optimization of CDS for implicit S/R and IRVs.
Name:
--deviate-omit-implicit-cds
Parameter:
This option enables (“1”) or disables (“0”) optimization of the component data structure (CDS) for implicit access to S/R and IRVs.
Default:
Forbid (“0”).
Notes:
Optimization of the CDS removes the data handles that are not required. Optimization is possible when the SWC is:
1. Singly instantiable,
2. Delivered as source code,
3. RTE generator is in vendor mode,
4. This option is enabled.
Example:
To enable optimization of the CDS for implicit S/R and IRVs:
--deviate-omit-implicit-cds=1
Command-line options
47
RTA-RTE V6.2.0
Reference Manual
3.29
--deviate-physical-dimension-compatibility
Description:
Specify physical dimension compatibility rules.
Name:
--deviate-physical-dimension-compatibility
Parameter:
This option enables (“1”) or disables (“0”) an RTA-RTE deviation from
the AUTOSAR RTE specification.
Default:
Disabled (“0”).
Notes:
This option modifies how the RTE generator validates compatibility
of physical dimensions. By default RTA-RTE validates according to
AUTOSAR rules and thus the physical dimensions must have the
same short-name and attributes. However when this option is enabled RTA-RTE only checks the attributes, e.g. length exponent,
match and permits the short-names to differ. This enables different
elements that represent the same physical dimensions to be connected but should be used with care since physical dimensions with
matching attributes can still represent different physical quantities.
See the AUTOSAR documentation for further details.
Example:
To enable non-AUTOSAR compatibility rules for physical dimension
comaptibility:
--deviate-physical-dimension-compatibility=1
48
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.30
--deviate-prefer-no-empty-executions
Description:
Enable (“on” or “1”) or disable (“off” or “0”) optimizations to
runnable entity scheduling that avoid empty executions of tasks
containing only runnables (or schedulable entities) triggered by the
same source, at the expense of loss of the guarantee that the
runnables will execute after being activated during the execution of
the task.
Name:
--deviate-prefer-no-empty-executions
Parameter:
This option enables (“on” or “1”) or disables (“off” or “0”) optimizations to the scheduling of runnables that reduce execution overhead
but cause the behavior to deviate from the AUTOSAR specification
and may cause activations occurring during runnable execution to
be delayed or lost.
Default:
Disabled (“off”).
Notes:
When enabled, activation flags are elided for tasks containing only
runnables that are activated by the same trigger source and such
tasks are required to be configured with an activation limit of one.
This avoids empty task executions in the case of bursts of runnable
activations but activations occurring while the task executes are delayed or lost, deviating from the AUTOSAR requirement that activations of a runnable during its execution be honored.
Example:
--deviate-prefer-no-empty-executions=on
Command-line options
49
RTA-RTE V6.2.0
Reference Manual
3.31
--deviate-split-swci-support
Description:
Split Sw-Cs across OsApplications
Name:
--deviate-split-swci-support
Parameter:
This option enables (“on” or “1”) or disables (“off” or “0”) splitting
ApplicationSofwareComponents across protection boundaries, i.e.
by mapping the Runnables to OsTasks in different OsApplications.
Default:
Disabled (“off”).
Notes:
When enabled, this option allows RteEvents from a SWCT to be
mapped to OsTasks in different OsApplications, in violation of AUTOSAR 4.0.3 [rte_sws_7347].
When this option is enabled, InterrunnableVariables might need
to cross protection boundaries. RTA-RTE will silently augment the
input model with port communication to handle this case, causing
the IoC to be invoked where needed.
Example:
To map runnables from the same SWCInstance to OsTasks in different OsApplications,
--deviate-split-swci-support=on
50
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.32
--deviate-task-sections
Description:
Modify the section names used by RTA-RTE to locate task bodies.
When enabled, each task body is contained within a section named
after the task; e.g. “RTE_START_SEC_TASKBODY_<TaskName>”.
Name:
--deviate-task-sections
Parameter:
This option takes a single parameter to switch the option on or off.
Supported values are “on” and “off”.
Default:
Standard AUTOSAR naming convention (“off”)
Notes:
Rte_MemMap.h must be modified to support the new section names.
Example:
To place task bodies into their own memory sections:
--deviate-task-sections=on
Command-line options
51
RTA-RTE V6.2.0
Reference Manual
3.33
--deviate-trace-implicit-api
Description:
Enable generation of VFB trace hooks for implicit API.
Name:
--deviate-trace-implicit-api
Parameter:
This option enables (“1”) or disables (“0”) an RTA-RTE deviation from
the AUTOSAR RTE specification. When set VFB trace hook calls are
added for implicit API functions / macros.
Default:
Disabled (“0”).
Notes:
None.
Example:
To enable VFB trace hook generation for the implicit API:
--deviate-trace-implicit-api=1
52
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.34
--deviate-unconnected-pmode-behavior
Description:
Control behavior of unconnected mode PPorts.
Name:
--deviate-unconnected-pmode-behavior
Parameter:
This option controls whether a mode manager Rte_Switch API stores
the current mode (“on”) or discards the input parameters (“off”).
When enabled the behavior of the API is an RTA-RTE deviation from
the AUTOSAR RTE specification since AUTOSAR requires an unconnected mode manager to discard the inputs.
Default:
Disabled (“off”).
Notes:
None.
Example:
To enable storing of the current mode by an unconnected mode manager:
--deviate-unconnected-pmode-behavior=on
Command-line options
53
RTA-RTE V6.2.0
Reference Manual
3.35
--diagnostic
Description:
Display RTE generator diagnostic information.
Name:
--diagnostic
Parameter:
None
Default:
N/A
Notes:
Create an HTML diagnostic report including RTE generator and plugin versions, OS version and environment variables.
The diagnostic report is written to diagnostic.htm. The output location, but not the filename, of the report can be modified using the
--output option.
Example:
To enable generation of the diagnostic report:
--diagnostic
54
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.36
--disable-warning
Description:
Disable display of specified warning.
Name:
--disable-warning
Parameter:
The option takes a single parameter. <STR>, that specifies the identifier of the warning or informational message to be disabled. The
option can be specified multiple times to disable multiple warnings.
Default:
#pragma message
Notes:
This option can disable the display of both warning and informational messages. When disabled RTA-RTE does not show the message and does not count the warning or information in the totals.
This option can be disabled within the INI file by setting
the flag DisableWarningOption to “disable” within the
section Options.
Example:
To disable information message I53-7701:
--disable-warning=I53-7701
Command-line options
55
RTA-RTE V6.2.0
Reference Manual
3.37
--error-as-warning
This option is deprecated and will be removed in a future version of RTA-RTE.
It should not be used in new projects. Existing projects should be updated
to no longer use this option.
Description:
Demote specific error to warning.
Name:
--error-as-warning
Parameter:
The option takes a single parameter <STR>, that specifies the identifier of the error message to be demoted to a warning. The option
can be specified multiple times to demote multiple errors.
Default:
N/A
Notes:
This option produces undefined behavior and should not be
used.
This option should be disabled in production projects by adding
ErrorAsWarningOption=disable to the [Options] section of
RTEGen.ini.
This option demotes the severity of a message from “E” (error) to
“W” (warning). As a result, RTA-RTE does not stop processing and
will continue to attempt to generate code.
Because an error has occurred, behavior in subsequent steps is undefined.
The option might be used during debugging to gather knowledge
about generator bugs or problems with the input configuration.
Example:
To demote error message E53-1234 to W53-1234:
--error-as-warning=E53-1234
56
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.38
--error-report
Description:
Select the message output method.
Name:
--error-report
Parameter:
This option takes a single parameter, <Method>, that specifies the
destination and format of the Information, Warning, and Error messages. Supported values are
• console format messages and write to the standard error
stream.
• file create file Rte.err. Format the messages as for console
and write them to this file along with a summary.
• xml create file RteErr.xml. Format the errors and summary in
XML and write to the file.
Default:
“console”
Notes:
Example:
To send all generated errors to a file use the following option:
--error-report=file
Command-line options
57
RTA-RTE V6.2.0
Reference Manual
3.39
--exclusive-area-optimization
Description:
Set optimization policy of RTE exlusive area APIs.
Name:
--exclusive-area-optimization
Parameter:
This option takes a single parameter, <P>, that specifies whether to
“enable” or disable “disable” optimization
Default:
“enable”
Notes:
When exclusive area optimization is disabled:
• For
explicitly accessed exclusive areas the generated
_
Rte Enter/Rte_Exit APIs are not mapped “null” implementations even when all accessors are already in mutual exclusion
(e.g. mapped to same task).
• For implicitly accessed exclusive areas, RTA-RTE will perform no
optimization to “null” implementation of enter/exit locks created
within the highest priority task.
Example:
To disable optimization of exclusive area access:
--exclusive-area-optimization=disable
58
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.40
--fast-init
Description:
Enable fast activation for mode switch events.
Name:
--fast-init
Parameter:
This option takes a single parameter, <REF>, that specifies either an
atomic SWC type or a ModeSwitchEvent.
Default:
The default activation policy is AUTOSAR compliant activation therefore this option needs to be specified for each event that is to be
activated by the non-AUTOSAR compliant mechanism.
Notes:
Enables ModeSwitchEvents to be activated by a non-AUTOSAR compliant mechanism (for example, a function call from the body of a
task started outside the control of the RTE). ModeSwitchEvents may
be specified either individually by name or as a group by naming the
SWC type to which they belong. This avoids the complexity inherent
in AUTOSAR-compliant activation for mode switch activations and is
especially useful for “init” runnables that are activated only once.
Example:
To enable fast activation for RTE Event ev1 within an internal behavior IB:
--fast-init=/pkg/IB/ev1
Command-line options
59
RTA-RTE V6.2.0
Reference Manual
3.41
--file
Description:
Read options from command file.
Name:
--file
Parameter:
The file from which commands are read.
Default:
N/A
Notes:
Read command-line options from the specified file in addition to any
read from the command line. The option can be used recursively; a
file read using --file can include other files.
The ‘@’ character can be used as a synonym for the -file option.
The space separating ‘@’ and <FILE> into separate command-line
arguments is optional.
Command line parameters included with this must observe the same
rules as if they were specified directly on the command line with the
exception that options can be split across multiple lines.
Comments can be included in a command file. A comment starts
with semicolon character (‘;’) either at the start of the line or after
some whitespace. Text up to the end of the line is ignored.
The file should be a plain ASCII text file. No special file extension is
required.
Example:
The following examples both read options from the file project.rte:
--file=project.rte
@project.rte
60
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.42
--force-basic-tasks
Description:
Force basic tasks.
Name:
--force-basic-tasks
Parameter:
This option takes no parameters. If omitted, then the task’s forcedbasic semantics are taken from the ECU Configuration file (see Section 4.19.2).
Default:
N/A
Notes:
When specified RTA-RTE uses forced-basic semantics (see RTA-RTE
User Guide) for all tasks in the ECU instance for which the RTE is
being generated. This option overrides any settings in the ECU Configuration file.
Example:
To enable force-basic semantics for all tasks:
--force-basic-tasks
Command-line options
61
RTA-RTE V6.2.0
Reference Manual
3.43
--have-64bit-int-types
Description:
Enable support for 64-bit platform types for use within generated
data-transformation.
Name:
--have-64bit-int-types
Parameter:
This option takes a single parameter, <P>, that specifies whether to
enable (‘1’) or disable (‘0’) the use of 64-bit types.
Default:
Disabled (‘0’)
Notes:
This option enables use
transformation functions.
by AUTOSAR the option is
must be defined when the
Example:
To indicate to RTA-RTE that 64-bit types are available:
of 64-bit types within generated dataSince these types are not standardized
disabled by default. If enabled the types
generated RTE is compiled.
--have-64bit-int-types=1
62
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.44
--help
Description:
Display RTE generator help.
Name:
--help
Parameter:
None
Default:
N/A
Notes:
Print the usage information on the standard output. Brief usage information is presented when using -?/-h and more detailed information with --help.
Example:
To display the help text: --help
Command-line options
63
RTA-RTE V6.2.0
Reference Manual
3.45
--implicit-allocation-method
Description:
Select the allocation method used by RTA-RTE for creating implicit
communication buffers. Supported methods are ’overlay’ and ’task’.
Name:
--implicit-allocation-method
Parameter:
This option takes a single parameter which is the method to use.
Supported values are “task” and “overlay”.
Default:
“overlay”
Notes:
Method “task” causes a separate structure to be created and
instantiated by RTA-RTE for each task’s implicit buffers.
The
structure instance is allocated to its own memory section called
SEC_VAR_IMPLICITSR_<TASK> where <TASK> is the task name in uppercase. Method “overlay” creates a single structure where tasks
that cannot preempt (e.g. those at the same priority) have overlayed
implicit buffers.
Example:
To enable separate structures for each task’s implicit buffers:
--implicit-allocation-method=task
64
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.46
--implicit-read-return-const
Description:
Control whether or nor the CONST or VAR compiler abstraction
macros are used to cast the return value from Rte_IRead.
Name:
--implicit-read-return-const
Parameter:
This option takes a single integer parameter which defines cast used.
0 Use of CONST cast disabled; the API mapping uses a VAR cast.
1 Use of CONST cast enabled.
Default:
1 (CONST cast).
Notes:
None.
Example:
To enable use of a VAR cast:
--implicit-read-return-const=0
Command-line options
65
RTA-RTE V6.2.0
Reference Manual
3.47
--implicit-use-global-buffers
Description:
Enable or disable use of global receive buffers in place of taskspecific buffers for implicit communications. This optimization is dependent on task preemption but when possible can save RAM since
no additional copies of the global data are required.
Name:
--implicit-use-global-buffers
Parameter:
This option takes a single integer parameter which defines the enabled optimizations.
0 Optimization disabled; all implicit communication uses AUTOSAR
compliant task-specific buffers.
1 Optimization of implicit communication to use global buffers is enabled. The possible optimization depends on the relative priorities of tasks containing readers and writers: for best results
either map to tasks at the same priority or map to the same
task.
2 As ’1’ plus all ’fast-init’ tasks use global buffer access for implicit
communication. For ’fast-init’ tasks the optimization occurs irrespective of the task mapping of readers and writers since it
is assumed that execution of the ’fast-init’ tasks is complete
before periodic runnables (and hence normal RTE tasks) start.
Default:
0 (optimization disabled and AUTOSAR compliant task-specific
buffers used).
Notes:
None.
Example:
To enable use by the generated RTE of global receive buffers:
--implicit-use-global-buffers=1
66
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.48
--incremental-build
Description:
Incremental Build.
Name:
--incremental-build
Parameter:
This option takes a single parameter that enables (‘1’) or disables
(‘0’) incremental output of generated files. If not specified incremental output is disabled.
Default:
Build all files (incremental build disabled).
Notes:
When enabled, RTA-RTE generates files to a temporary folder and
only overwrites files in the destination folder if the contents have
changed.
This option turns on the --notimestamps option.
Example:
To enable incremental build:
--incremental-build=1
Command-line options
67
RTA-RTE V6.2.0
Reference Manual
3.49
--initial-value-rounding
Description:
Select the rounding behavior for the calculation of initial values for
integer data from physical values.
Name:
--initial-value-rounding
Parameter:
This option takes a single parameter which specifies the required
rounding behavior for the calculation of initial values for integer data
types from physical values. The supported rounding behaviors are
‘truncate’ meaning truncation towards zero and ‘nearest’ meaning
rounding to nearest, with half values rounding away from zero.
Default:
truncate
Notes:
When a physical value is given with an ApplicationValueSpecification the computation of the corresponding internal value may result
in a fractional value that must be rounded in the case that the destination data type is an integer. This option allows that rounding
behavior to be selected.
The ‘truncate’ behavior means to truncate towards zero, so for example 2.3 and 2.8 both become 2 and −1.2 and −1.9 both become
−1.
The ‘nearest’ behavior means to round to nearest, with half values
rounding away from zero, so for example 2.4 becomes 2, 2.8 and 2.5
both become 3, −1.2 becomes −1 and −1.7 and −1.5 both become
−2.
Example:
To select rounding to nearest behavior:
--initial-value-rounding=nearest
68
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.50
--ioc-header
Description:
Set the IOC header file used.
Name:
--ioc-header
Parameter:
This option takes a single parameter, <FILE>, that specifies the
name of the IOC header file to use within generated code.
Default:
None.
Notes:
This option is valid in vendor mode only.
Example:
To use IOC header ioc.h:
--ioc-header=ioc.h
Command-line options
69
RTA-RTE V6.2.0
Reference Manual
3.51
--ioc-xml-namespace
Description:
Set the XML namespace URI used in generated IOC configuration file.
Name:
--ioc-xml-namespace
Parameter:
This option takes a single parameter, <URI>, that specifies the
namespace URI to be used within the generated IOC configuration
file.
Default:
If this option is not specified the default namespace URI is the R4.0
default namespace.
Notes:
This option is supported by the RTA-IOC OS plug-in.
Example:
To use http://namespace as the namespace URI when generating
the IOC configuration file, use:
--ioc-xml-namespace=http://namespace
70
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.52
--local-mcsd
Description:
Report “local McSupportData” for a specific software module.
Name:
--local-mcsd
Parameter:
This option takes a single parameter that must be an absolute reference to the ApplicationSoftwareComponentType type whose internal
data are to be reported in McSupportData.
Default:
N/A
Notes:
This is a non-AUTOSAR generation phase that generates McSupportData for specific software modules. RTA-RTE will generate an McSupportData report containing the staticMemorys, constantMemorys and perInstanceParameters of the given modules. To include
multiple modules in the McSupportData, specify the --local-mcsd
option multiple times on the command line. You cannot mix “local
MCSD phase” with any other phase in the same run of RTA-RTE.
Example:
To generate McSupportData for two hypothetical Software Component Types swcA and swcB:
--local-mcsd=/MyPackage/ApplicationSwComponentTypes/swcA --local-mcsd=
Command-line options
71
RTA-RTE V6.2.0
Reference Manual
3.53
--makedep
Description:
Output dependency information for generated files.
Name:
--makedep
Parameter:
The option takes one parameter, <FILE>, which is the file to which
dependency information is to be written.
Default:
N/A
Notes:
None.
Example:
To enable generation of dependency information and output it to file
rte.dep use:
--makedep=rte.dep
72
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.54
--mcore-spinlocks-always
Description:
Enable spinlocks in multicore mode handling.
Name:
--mcore-spinlocks-always
Parameter:
This option enables (“1”) or disables (“0”) spinlocks in multicore
mode handling.
Default:
Disabled (“0”).
Notes:
When enabled, RTA-RTE emits spinlocks for concurrency protection
in Mode APIs. At the time of writing, RTA-RTE does not optimize spinlocks, so specifying this option will cause all Mode Machine Instances
to use spinlocks even if there is no inter-core communication to protect against. For this reason, the option should not be used if the
input model contains no inter-core mode handling.
Example:
Enable inter-core mode handling: --mcore-spinlocks-always=1
Command-line options
73
RTA-RTE V6.2.0
Reference Manual
3.55
--mcsd-policy
Description:
Specify options pertaining to the output of Measurement and Calibration Support Data (MCSD).
Name:
--mcsd-policy
Parameter:
This option takes a single parameter: a comma-separated list of options which modify the MCSD as follows:
emit-memorys emits McDataInstance containers for any BSW or
ASW Static or Constant Memory.
phys-constrs-always RTA-RTE shall always write PhysConstrs related to every McDataInstance. If necessary, the PhysConstr
will be taken from The ApplicationDataType, ImplementationDataType, CompuMethod (for enumerated types) or SwBaseType (for Category NONE, 2C or BOOLEAN). If no PhysConstr
can be found or calculated, an error is raised.
mcfunction-from-shortname For all McDataInstances where RTARTE sees a relevant DataPrototype, that DataPrototype’s shortName is copied to the McDataInstance’s McFunction. This policy is deprecated; it was implemented as a workaround for use
before RTA-RTE exported McFunction correctly.
struct-element-symbols For McDataInstances that are structure
elements, the C names for the elements are emitted as their
symbols. These are not global linker symbols but they do allow the full C expressions to access the elements to be constructed.
Default:
N/A
Notes:
N/A
Example:
--mcsd-policy=emit-memorys
74
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.56
--measurement
Description:
Globally enable (or disable) support for measurement.
Name:
--measurement
Parameter:
The option takes a single parameter, <V>, that specifies whether
measurement is enabled (“1”, “2” and “3”) or disabled (“0”)
Default:
Enabled (“1”)
Notes:
With parameter “1”, each data element, client-server argument and
inter-runnable variable that is to be measured must be configured
separately.
With parameter “2”, measurement is enabled for all data elements
and inter-runnable variable irrespective of the configuration within
the XML input. This setting therefore enables items to be measured
in 3rd party components (for which source is available) without modifying the source XML.
Parameter “3” extends “2” to also measure all client-server arguments.
For RTE generation phase, this option can be set both in the ECUC
file and on the command-line. If specified in both places then RTARTE will use the command-line value — this enables simple override
of the “fixed” configuration value.
Example:
To enable measurement for all data elements (including interrunnable variables) irrespective of the settings in the input configuration use the following option:
--measurement=2
Command-line options
75
RTA-RTE V6.2.0
Reference Manual
3.57
--memory-sections
Description:
Specify location of the Memory Section Description File.
Name:
--memory-sections
Parameter:
<PATH> — specifies the folder containing the memory section description file. The specification can be an absolute or relative path.
A relative path is interpreted relative to the folder containing the
current folder.
Default:
File “memsect.xml” within the folder containing the application executable. If the file is specified both in the INI configuration file and
on the command-line the latter takes precedence.
Notes:
See RTA-RTE Toolchain Integration Guide for further details on using
the Memory Section Description File to adapt the AUTOSAR compiler
abstraction usage within generated code.
Example:
To use memory section description file mymemsect.xml:
--memory-sections=mymemsect.xml
76
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.58
--notimestamps
Description:
Disable timestamps in generated files.
Name:
--notimestamps
Parameter:
None
Default:
Include timestamps.
Notes:
Output fixed-text banner (omit date and time of generation in generated files). This option is useful when the generated output will be
programmatically compared, e.g. by a source control system.
Example:
To disable timestamp generation:
--notimestamps
Command-line options
77
RTA-RTE V6.2.0
Reference Manual
3.59
--operating-system
Description:
Select which OS support to use.
Name:
--operating-system
Parameter:
The option takes a single parameter, <OS> that is the name of the
OS to use, for example autosar10.
Default:
Dependent on selected backend.
Notes:
The selected OS determines both the OS API used within the generated RTE and also the form of the generated OS configuration file (if
any).
Example:
To select the autosar40 OS support:
--operating-system=autosar40
78
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.60
--optimize
Description:
Set the optimization strategy for the generated RTE.
Name:
--optimize
Parameter:
This option takes a single parameter, <TYPE> that specifies the optimization type. Supported values are “Runtime” (optimize for speed)
and “Memory” (optimize for code size).
Default:
“Runtime” (speed)
Notes:
When optimized for “Memory” (size) RTA-RTE invokes the COM API
directly to access non-queued signals rather than allocating buffers
for storage. The optimization strategy can also be set using the RTE
Generation parameters within the ECU Configuration description. A
setting on the command-line overrides a setting in the ECU Configuration description.
The short-form of this option is an uppercase letter “O”.
For RTE generation phase, this option can be set both in the ECUC file
and on the command-line. If specified in both places then RTA-RTE
will use the command-line value — this enables a simple override of
the “fixed” configuration value.
Example:
To enable optimization for “memory” usage:
--optimize=Memory
Command-line options
79
RTA-RTE V6.2.0
Reference Manual
3.61
--os-define-osenv
Description:
Define OSENV within Rte_Const.h.
Name:
--os-define-osenv
Parameter:
This option takes a single parameter which is the OSENV <NAME> to
define.
Default:
If this option is not specified, then OSENV_<NAME> must be defined
when the RTE is compiled.
Notes:
Usually the OSENV_<NAME> should be defined when the RTE is compiled. If it is not practical to change compiler flags for your project,
for example the RTE is generated and compiled at different sites,
then this option allows you to set the symbol when generating the
RTE.
Example:
To define RTA-OSEK as the OS environment:
--os-define-osenv=RTAOSEK
80
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.62
--os-fp
Description:
Set whether or not user code invoked by RTE generated tasks uses
floating-point operations/arithmetic support.
Name:
--os-fp
Parameter:
This option takes a single parameter that specifies whether floating
point usage is disabled (“off” or “0”) or enabled (“on” or “1”).
Default:
Enabled (“on”).
Notes:
This option only affects the OIL configuration file created by AUTOSAR R1.0 OS plug-in. Its usage enables the additional optimizations included in RTA-OSEK 5.0 for when tasks do not use floating
point.
Example:
To disable FP usage:
--os-fp=off
Command-line options
81
RTA-RTE V6.2.0
Reference Manual
3.63
--os-header
Description:
Set the OS header file used.
Name:
--os-header
Parameter:
This option takes a single parameter, <FILE>, that specifies the
name of the OS header file to use within generated code.
Default:
The default OS header files used are suitable for the primary target
OS of the selected OS plug-in. However this option permits a different value to be set.
Notes:
This option is supported by the VFB Tracing and the OS configuration
plug-ins.
Example:
To select OS2.h as the OS header:
--os-header=OS2.h
82
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.64
--os-output-param
Description:
Output all OS task parameters and references OR output only those
that have changed.
Name:
--os-output-param
Parameter:
This option takes a single parameter, <P>, that specifies whether
task parameters and/or referenced should be copied from the input to the generated OS configuration file. Supported values are
“changed” and “all”.
Default:
“changed”
Notes:
When set to (“all”) this option causes RTA-RTE to output all OS
task parameters (priority, activation limit and schedule) and OS task
references (OS resources) regardless of whether they have been
changed.
When set to (“changed”) this option causes RTA-RTE to output only
those OS task parameters and OS task references (OS resources)
that it has modified.
This option can be used with both the AUTOSAR30 and AUTOSAR40
OS support. See the RTA-RTE Toolchain Integration Guide for further
details on working with RTA-RTE and the osparam option.
Example:
To output all OS parameters in the generated OS configuration:
--os-output-param=all
Command-line options
83
RTA-RTE V6.2.0
Reference Manual
3.65
--os-permit-extended-tasks
Description:
Configure whether the RTE generator is permitted to create extended tasks.
Name:
--os-permit-extended-tasks
Parameter:
This option takes a single parameter, <P>, that specifies whether
generation of extended tasks by RTA-RTE is permitted (“1”) or forbidden (“0”).
Default:
Enabled (“1”).
Notes:
If extended tasks are disabled (option parameter “0”) then certain
runnable-entity mappings that require extended tasks are invalid;
most notably the mixing of runnables triggered by TimingEvents
with runnables triggered by other RTE Events.
Example:
To disable support for extended tasks:
--os-permit-extended-tasks=0
84
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.66
--os-task-as-function
Description:
Determine if generated tasks are created using the AUTOSAR OS
macro TASK or as function definitions.
Name:
--os-task-as-function
Parameter:
This option takes a single parameter, <P>, that specifies whether
tasks are output as functions or TASKs. When defined as “1” generated tasks are created as functions which can be invoked by legacy
systems. See the RTA-RTE Toolchain Integration Guide for details.
Default:
Disabled (“0”).
Notes:
This option is supported by the C Output and OS output plug-ins.
When enabled in vendor mode no task-specific header files are referenced within the generated task files.
When enabled, RTA-RTE replaces the TASK() macro in generated
output with a function definition.
This option is incompatible with runnables that specify
a minimum start interval since the execution of such
runnables must be controlled by the RTE.
Example:
To enable generation as tasks, use:
--os-task-as-function=1
Command-line options
85
RTA-RTE V6.2.0
Reference Manual
3.67
--os-xml-namespace
This option is deprecated and will be removed in a future version of RTA-RTE.
It should not be used in new projects. Existing projects should be updated
to no longer use this option.
Description:
Set the XML namespace URI used in generated OS configuration file.
Name:
--os-xml-namespace
Parameter:
This option takes a single parameter, <URI>, that specifies the
namespace URI to be used for the generated OS configuration file.
Default:
If this option is not specified the default is default namespace URI is
http://autosar.org/3.0.2.
Notes:
This option can be used with the AUTOSAR30 OS support.
Example:
To use http://namespace as the namespace URI when generating
the OS configuration file, use:
--os-xml-namespace=http://namespace
86
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.68
--output
Description:
Direct all generated output files whose names match pattern <PAT>
(which can include wild cards) to folder <FLDR>.
Name:
--output
Parameter:
The option takes one parameter that typically consists of the pattern <PAT> and the folder <FLDR>. The specification of <PAT> must
be enclosed in square brackets and precedes <FLDR>, for example
--output=[*.c]Source.
If either <PAT> or <FLDR> are omitted then this option is ignored except for the value “check_only” which, when present, causes the
RTE generator to run, display detected errors and discard all output
other than the error log.
Default:
Files are generated in the current folder.
Notes:
For further details on the use of the --output option including how
multiple options are parsed see Section 2.2.1.
Example:
To redirect all C files to folderA and all other files to folderB use
the following two options in sequence:
--output=[*.c]folderA --output=[*]folderB
To log errors to a file and discard all other output use:
--error-report=file --output=check_only
Command-line options
87
RTA-RTE V6.2.0
Reference Manual
3.69
--period
Description:
Declare the period at which Rte_MainFunction will be called
Name:
--period
Parameter:
This option takes a single parameter, <SEC> that specifies the time
between invocations of Rte_MainFunction in seconds.
Default:
0.01 (10ms period)
Notes:
The value of <SEC> must be chosen such that all Minimum Start Intervals are integral multiples of <SEC>. For maximum efficiency, choose
Greatest Common Divisor of the Minimum Start Intervals in the ECU
Extract. If no Minimum Start Intervals are used then this option is
not relevant.
Example:
To notify RTA-RTE that the Rte_MainFunction API will be invoked
every 50ms: --period=0.05
88
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.70
--preferred-intra-core-protection-scheme
Description:
Select the preferred scheme for the implementation of intra-core
concurrency protection in RTE internal code.
Name:
--preferred-intra-core-protection-scheme
Parameter:
This option takes a single parameter which names the intra-core
concurrency protection strategy that is preferred for RTE internal code. Supported schemes are per-core-resources, where
an RTE internal OS resource for each processor core is locked,
os-interrupt-blocking, where OS interrupts are suspended and
all-interrupt-blocking where all interrupts are suspended.
Default:
per-core-resources
Notes:
The scheme selected with this option applies to RTE internal code
where the accesses being protected are all from execution contexts
on the same processor core and where the choice of scheme is not
limited due to there being accesses from particular execution contexts (e.g. interrupt contexts) or due to the actions of the code being
protected.
This option has no effect on the APIs implementing ExclusiveAreas
declared in software components.
Note that at the time of writing this option only applies to a small
subset of the generated code.
Example:
To prefer the use of OS interrupt blocking within RTE internal code:
--preferred-intra-core-protection-scheme=os-interrupt-blocking
With this setting OS interrupt blocking will be used where possible
but there may be some places where this is not possible. For example where there is access via a BSW interrupt entity from a category
1 interrupt, all interrupt blocking will be used. On the other hand,
where the protected code calls OS APIs such as ActivateTask the
locking of per-core OS resources will be used, since it is not valid to
call such APIs with interrupts disabled.
Command-line options
89
RTA-RTE V6.2.0
Reference Manual
3.71
--protection-threshold-copy-bytes
Description:
Tune the amount of data that can be copied in a critical section when
concurrency protection is needed.
Name:
--protection-threshold-copy-bytes
Parameter:
This option takes a single parameter: an integer expressing the
threshold number of bytes that can be copied in one critical section.
Supported values:
• “0”: Batch all copy operations needing concurrency protection
in a single critical section. May reduce latency.
• “1”: Each copy operation needing concurrency protection is
placed in its own critical section. May reduce jitter.
• values larger than 1: apply algorithm as per notes below.
Default:
“0”
Notes:
For thresholds greater than 1, RTA-RTE batches copy operations requiring concurrency protection:
• When there are copies to be made that require concurrency protection, RTA-RTE enters a critical section (e.g. by GetResource).
• RTA-RTE holds the critical section open, potentially across multiple copy operations, while there are still items to copy and the
cumulative work performed (as defined below) within the critical
section does not exceed the threshold.
• RTA-RTE releases the critical section.
• If not all the copy operations are complete, RTA-RTE repeats from
item 1 until all the items are copied.
Work Performed = ( Number of bytes of data copied ) +
( Estimate of equivalent work, e.g. arithmetic operations )
Example:
90
To enable a separate lock around each copy action:
--protection-threshold-copy-bytes=1
To
set
protection
threshold
to
32
bytes:
--protection-threshold-copy-bytes=32
In this example, if there several data items to copy totalling
60 bytes, RTA-RTE would release the critical section (e.g. by
ReleaseResource followed by GetResource) once during the batch
of copy operations.
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.72
--quiet
Description:
Control the text output.
Name:
--quiet
Parameter:
The option takes a single parameter; an integer specifying the level
of output required. Valid values are:
0 Verbose.
1 Normal: Suppress certain plug-in information messages (default).
2 Quiet: No output other than RTA-RTE banner during normal operation.
3 Silent: output at all during normal operation.
Default:
Normal output (level 1).
Notes:
None.
Example:
To suppress all output during normal operation:
--quiet=3
Command-line options
91
RTA-RTE V6.2.0
Reference Manual
3.73
--report
Description:
Enable output of XML report.
Name:
--report
Parameter:
This option takes a single parameter that specifies the the report
name and, optionally, the report template file.
Default:
None.
Notes:
None.
Example:
To generate the RteObjects report with a template:
--report=[template.xml]RteObjects
To generate the same report but without a template:
--report=[null]RteObjects
92
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.74
--rte
Description:
Select “RTE” generation phase to generate an RTE for the specified
ECU name.
Name:
--rte
Parameter:
This option takes a single parameter, <ECUI> that specifies the ECU
instance or the ECU configuration (ECUC value collection in R4.0) for
which RTE generation should occur. The System element must be
referenced from the ECU configuration. For R4.0 the parameter can
be “auto” which causes the RTE generator to search for and use the
single EcucValueCollection present in the input.
Default:
N/A
Notes:
The ECU instance <ECUI> must be specified using an absolute instance reference. (See Section 4.2.4.)
Example:
To enable RTE generation for /pkg/ecu:
--rte=/pkg/ecu
To enable automatic search for the ECUC value collection and processing of the ECU extract (R4.0 only):
--rte=auto
Command-line options
93
RTA-RTE V6.2.0
Reference Manual
3.75
--samples
Description:
Enable creation of SWC skeleton files.
Name:
--samples
Parameter:
The --samples option takes a single parameter that specifies the
samples required.
swc : Create skeleton code files consisting of empty runnable-entity
bodies for each runnable in the SWC. The generated files are
named Rte_<name>.c where <name> is the SWC name.
memmap : Create skeletons of SWC-specific memory-mapping
files. The generated files are named <name>_MemMap.h where
<name> is the SWC name.
Default:
None.
Notes:
Generated samples overwrite existing files with the same name.
The generated samples are intended to be examples only, and
should be adapted for the application and target hardware before
use.
Example:
To enable sample generation for SWCs:
--samples=swc
94
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.76
--strict-config-check
Description:
Enable RTE validation of input OS configuration.
Name:
--strict-config-check
Parameter:
This option takes a single parameter, <P>, that specifies whether
to enable (‘on’ or ‘weak’) or disable (‘off’) the strict configuration
checks.
Default:
Disable check.
Notes:
RTA-RTE supports the AUTOSAR strict configuration check; when enabled the RTE configuration must not require any OS objects that
are not already present in the input configuration. For example, all
runnables must be mapped to existing tasks and, if necessary, use
pre-declared OsEvents and ScheduleTable/alarms for triggering.
RTA-RTE also supports “weak” configuration checks — this changes
the reported error to a warning, allowing the build to continue.
Example:
To enable strict configuration checks:
--strict-config-check=on
Command-line options
95
RTA-RTE V6.2.0
Reference Manual
3.77
--strict-initial-values-check
Description:
Enable RTE validation of input OS configuration.
Name:
--strict-initial-values-check
Parameter:
This option takes a single parameter, <P>, that specifies the behavior
when an uninitialized calprm is encountered.
1. info: to output an informational message
2. warn: to output a warning message
3. error: to output an error message
4. none: to disable the detection of uninitialized calprms
Default:
Error.
Notes:
Example:
To reduce the severity of an uninitialized calprm to a warning:
--strict-initial-values-check=warn
96
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.78
--strict-unconnected-rport-check
Description:
Permit unconnected RPorts.
Name:
--strict-unconnected-rport-check
Parameter:
This option takes one argument with the value ’off’, ’warn’ or
’error’, which specifies what RTA-RTE should do when it detects an
unconnected R-Port.
Default:
If the option is not specified, it is an error to have unconnected RPorts
Notes:
This
is
the
AUTOSAR
strictUnconnectedRPortCheck.
Example:
To allow RTA-RTE to accept an input model having unconnected require ports:
external
configuration
switch
--strict-unconnected-rport-check=off
To enable the check for unconnected RPorts and raise a warning
when such a port is encountered:
--strict-unconnected-rport-check=warn
Command-line options
97
RTA-RTE V6.2.0
Reference Manual
3.79
--sws
Description:
Selection of backend processor.
Name:
--sws
Parameter:
The parameter specifies the appropriate AUTOSAR release.
Default:
If this option is not specified then RTA-RTE examines the input XML
for an XML namespace and selects the appropriate backend processor automatically.
Notes:
The --sws option bypasses the namespace check and explicitly selects the backend processor. The set of valid parameter values depends on the installed backend processors; use the --help option
for the RTA-RTE frontend to show the valid list.
Example:
To explicitly select the R4.0 backend processor:
--sws=4.0
When explicitly selecting the backend processor ensure
that the input XML is conformant to the selected AUTOSAR release.
98
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.80
--task-recurrence
Description:
Set the recurrence for externally activated periodic tasks.
Name:
--task-recurrence
Parameter:
This option takes a single parameter that specifies the task/OsEvent
name and the recurrence rate in seconds as a task.event=seconds”
pair. The specification of an OsEvent name is optional; if omitted the
recurrence rate applies to activations of the task. Time values are
specified in seconds with a period as the decimal separator.
Default:
Create OS alarms and/or schedule table entries (or use existing
ones) to implement periodic RTE events.
Notes:
This option disables RTA-RTE’s generation of OS alarms and/or
schedule table entries for periodic events. Instead RTA-RTE uses the
specified task recurrences to both derive internal scaling for generated code (e.g. to map an RTE event with 20ms period to a task with
an explicit recurrence of 10ms) and to validate the mapping to detect erroneous cases (e.g. mapping an RTE event with period 10ms
to a task with an explicit recurrence of 20ms).
When this option is used for any task then it must be
used to specify recurrence rates for all tasks with periodic
events since it disables RTA-RTE’s support for generating
OS mechanisms to activate periodic events.
This option can be specified many times to provide recurrence rates
for multiple tasks. Alternatively the parameter can be specified as a
comma-separated list of task name/rate pairs.
Example:
To specify a recurrence rate of 20ms for taskA:
--task-recurrence taskA=0.02
To specify a recurrence rate of 10ms for OsEvent ev1:
--task-recurrence TaskA.ev1=0.01
Command-line options
99
RTA-RTE V6.2.0
Reference Manual
3.81
--template-path
Description:
Selection location of RTE library templates.
Name:
--template-path
Parameter:
This
option
takes
a
single
parameter
which
speci-
fies the folder containing RTE library files.
If a relative path is used, it is interpreted relative to the
RTA-RTE application executable.
Default:
Specified within RTE configuration INI file. If the template path is
specified both in the INI configuration file and on the command-line
the latter takes precedence.
Notes:
None
Example:
To select project-specific templates located in folderA:
--template-path=folderA
100
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.82
--test-license
Description:
Display RTE license information.
Name:
--test-license
Parameter:
None
Default:
N/A
Notes:
Perform a license check and display the result.
Example:
To test the license in use:
s --test-license
Command-line options
101
RTA-RTE V6.2.0
Reference Manual
3.83
--text-value-spec-policy
Description:
Adjust whether RTE writes symbols or numeric values for
TextValueSpecs
Name:
--text-value-spec-policy
Parameter:
compumethod-resolution TextValueSpec.value is interpreted
as a physical quantity to be looked up in a corresponding
TEXTTABLE or BITFIELD_TEXTTABLE CompuMethod. The numerical equivalent is written to the generated code. If the value
cannot be found RTA-RTE rejects the configuration with an error.
symbolic-pdav-always When
used
in
a
PortDefinedArgumentValue, TextValueSpec.value is treated
as a symbol that is to be copied directly into the generated code. Compile-time definitions must be provided when
compiling Rte.c.
Default:
compumethod-resolution
Notes:
N/A
Example:
--text-value-spec-policy=symbolic-pdav-always
102
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.84
--toolchain-significant-len
Description:
Specify number of significant characters in toolchain identifiers.
Name:
--toolchain-significant-len
Parameter:
This option takes a single parameter, <P>, that specifies the number
of significant characters.
Default:
31
Notes:
Indicates to the RTE generator the number of significant characters checked by the toolchain. The RTE generator will then issue a
warning if multiple RTE generated identifiers are not distinguishable
within the specified number of characters.
For RTE generation phase, this option can be set both in the ECUC file
and on the command-line. If specified in both places then RTA-RTE
will use the command-line value.
Example:
To set the number of significant characters to 60:
--toolchain-significant-len=60
Command-line options
103
RTA-RTE V6.2.0
Reference Manual
3.85
--use-partition-sections
Description:
Select whether or not partition-specific default memory sections
should be used for partition-local objects without a section specified
explicitly.
Name:
--use-partition-sections
Parameter:
This option takes a single parameter which enables (“on” or “1”) or
disables (“off” or “0”) use of partition-specific memory sections by
default for objects that are local to a partition and have no memory
section specified. When enabled, the name of the EcuCPartition is
used as the infix for the memory section name when one is configured, otherwise the name of the OsApplication is used.
Default:
Disabled (“off”) for AUTOSAR compliance.
Notes:
None.
Example:
To enable the use of partition-specific default memory sections:
--use-partition-sections=on
104
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.86
--variability-also-bind
Description:
Add a BindingTime that RTA-RTE will also try to honor.
Name:
--variability-also-bind
Parameter:
If used, this option must be given the parameter PRE-COMPILE-TIME
which is the only supported value at this time.
Default:
Only
instantiate
CODE-GENERATION-TIME
Notes:
N/A
Example:
--variability-also-bind=PRE-COMPILE-TIME
variability
with
BindingTime
Command-line options
105
RTA-RTE V6.2.0
Reference Manual
3.87
--version
Description:
Display RTE generator version.
Name:
--version
Parameter:
None
Default:
N/A
Notes:
Print the RTA-RTE product and RTE generator version information on
the standard output.
Example:
To display the RTA-RTE version: --version
106
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.88
--vfb-trace
Description:
Globally enable (or disable) the creation of VFB trace hooks in the
generated RTE.
Name:
--vfb-trace
Parameter:
This option takes a single parameter that specifies whether generation of hook functions is enabled (“on” or “1”) or disabled (“off” or
“0”).
Default:
Enabled (“on”)
Notes:
For the RTE generation phase, this option can be set both in the
ECUC file and on the command-line. If specified in both places then
RTA-RTE will use the command-line value.
Example:
To disable VFB trace hook generation from the command-line:
--vfb-trace=off
Command-line options
107
RTA-RTE V6.2.0
Reference Manual
3.89
--warn-directive
Description:
Set the name (excluding the ‘#’) of the C pre-processor directive
used to issue warnings.
Name:
--warn-directive
Parameter:
The option takes a single parameter, <STR>, that specifies the directive name.
Default:
#pragma message
Notes:
None.
Example:
To select #warn as the warning directive used in generated RTE code:
--warn-directive=warn
108
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.90
--warning-as-error
Description:
Set whether warnings are treated as errors.
Name:
--warning-as-error
Parameter:
The option takes a single parameter that specifies whether to enable
(‘1‘) or disable (‘0’) treatment of warnings as errors.
Default:
Treat warnings as warnings (‘0’)
Notes:
When enabled RTE treats any warning as an error and raises the
error level appropriately. Note that the warning message text itself
is not changed and thus may still refer to the error as a “warning”.
Note: If you wish to use this option along with --disable-warning
then you must turn the specific message back to a warning using
--error-as-warning.
Example:
To treat all warnings as errors but continue suppressing warning
W17-1023:
--warning-as-error=1
--disable-warning=W17-1023
--error-as-warning=E17-1023
Command-line options
109
RTA-RTE V6.2.0
Reference Manual
3.91
--xmlentity
Description:
Add the specified XML schema to the XML entity resolver.
Name:
--xmlentity
Parameter:
This option takes a single parameter, [<SYSID>]<PATH>, that specifies the system identifier and path to the schema file. The path can
be absolute or relative to the folder in which the RTE generator is
run.
Default:
N/A
Notes:
By default, RTA-RTE uses the XML namespace to identify the XSD
used for validation of the file. To support this RTA-RTE includes XSD
caching to reduce load by reusing read schemas. In some circumstances this approach may not be desired. For example, the R4.0
schemas use identical namespaces and therefore cannot be distinguished from each other. The --xmlentity option enables an association to be made between a system identifier (<SYSID>) and a path
to the associated schema.
When RTA-RTE encounters a schemaLocation attribute in an XML file
with a system identifier it uses the set of <SYSID> and path associations to attempt to map the identifier to a path. If this is successful,
the schema is read from the specified path rather than from the file
specified by the schemaLocation attribute.
When using the --xmlentity option it is recommended that schema
caching is disabled (see the --xmlschema option below). Doing this
allows schemas with the same namespace but different system identifiers to be resolved to different files.
Example:
Consider an XML file with schemaLocation attribute:
xsi:schemaLocation=’http://autosar.org/schema/r4.0 AUTOSAR_4-0-1.xsd’
To map AUTOSAR_4-0-1.xsd to a specific file use:
--xmlentity=[AUTOSAR_4-0-1.xsd]c:\schemas\ar401.xsd
110
Command-line options
RTA-RTE V6.2.0
Reference Manual
3.92
--xmlschema
Description:
Add the specified XML schema to the set of XSD files that are cached
before XML files are loaded. Cached schemas override schemas referenced from XML files if the file’s namespace and the schema’s
targetNamespace match.
Name:
--xmlschema
Parameter:
This option takes a single parameter, <PATH>, that specifies the
schema file to be cached. The special parameter value “no_cache”
disables schema caching entirely.
Default:
Specified in RTA-RTE configuration INI file. Use of the --xmlschema
option disables schema specification within the RTE configuration
file. Multiple schemas can be specified on the command-line by using the --xmlschema option multiple times.
Notes:
To reduce load times RTA-RTE caches read XML schema (XSD) files
that are specified by an XML file’s schemaLocation attribute. In
some circumstances this approach may not be desired. For example, the referenced XSD may be in an unsuitable location. The
--xmlschema option eases this problem by enabling a schema to be
preloaded. The preloaded schema is then used by RTA-RTE in preference to the referenced XSD file.
The schemaLocation attribute in an XML file associates a namespace URI with a schema file. A cached schema loaded using the
--xmlschema option will be used if it has the same targetNamespace
as the URI within the schemaLocation attribute.
When schema caching is disabled by using the no_cache parameter,
each XML file’s schemaLocation is used to locate the schema.
Example:
To select a specific schema for caching:
--xmlschema=file.xsd
To disable schema caching (and use the schema(s) specified by the
XML files instead):
--xmlschema=no_cache
Command-line options
111
RTA-RTE V6.2.0
Reference Manual
4
Configuration
The configuration language accepted by the RTE generator is standard XML Version 1.0.
RTA-RTE can accept and validate input defined by any version of the following AUTOSAR
XML schemas.
Release
R4.0
R4.2
Revision
Target Namespace
0001
http://autosar.org/schema/r4.0
0002
http://autosar.org/schema/r4.0
0003
http://autosar.org/schema/r4.0
0002
http://autosar.org/schema/r4.0
Different input files to the RTE generator can conform to schemas from different releases of AUTOSAR 4.x.y.
An RTE generator requires only a subset of the information that can be expressed by
elements defined by the AUTOSAR XML schema. Elements present in the input to RTARTE that are not required for RTE configuration are ignored as long as the definitions
are compliant with the input file’s associated AUTOSAR schema.
4.1
XML Namespaces
The input files can use XML namespaces provided the xmlns attribute is used to set the
namespace as follows:
• The default namespace is used if the AUTOSAR element includes the attribute
xmlns="<uri>" where <uri> identifies a schema by its target namespace.
• The namespace autosar is used if the AUTOSAR element includes the attribute
xmlns:autosar="<uri>" where <uri> identifies a schema by its target namespace.
In XML a namespace is defined by a URI that identifies a particular schema by its target namespace. The target namespaces supported by the RTE generator are defined
above.
Input files can be conformant to any XML namespace supported by RTA-RTE. Files
conformant to different schemas can be mixed within one execution of RTA-RTE. The
--xmlschema option can be used to pre-load XML schema (XSD) files and thus override
the setting of the schemaLocation attribute.
4.1.1
Defining Additional Namespaces
RTA-RTE is intended only for parsing RTE configuration information from XML conformant to the schemas as defined above.
AUTOSAR periodically releases updated versions of the XML schema files within a new
release that require use of a parser from a more recent version of RTA-RTE to handle
112
Configuration
RTA-RTE V6.2.0
Reference Manual
changes made in the release. This normally occurs only at major releases but occasionally occurs for a patch release. However there is always a delay between the AUTOSAR
release of the schema files and the availability of an updated RTA-RTE. Consequently
RTA-RTE includes a mechanism to enable the addition of one or more XML namespace
URIs so that XML conformant to the schema can be tested/used before any RTA-RTE
release is available from ETAS GmbH.
Adding a new namespace URI using the URIs section does not modify the
parser within RTA-RTE. Addition of a URI is therefore only appropriate when
the changes introduced in the new schema do not affect RTE configuration.
For example, to add URI http://autosar.org/4.3.0 associated with a hypothetical
AUTOSAR release for which an updated RTA-RTE has not yet been released the following
can be added to the RTE generator configuration file RTEGen.ini:
[URIs]
uri0=http://autosar.org/4.3.0
Each URI is specified as a key=value pair within the URIs section. Multiple URIs can be
added as long as each has a unique “key”. The order of entries within the URIs section
is not important.
When the new schema includes changes relevant to the RTE configuration
the effect on RTA-RTE is undefined and may include failure of the generator
and/or generated code. Therefore caution is required when using the generated code if any input file is conformant to a schema for which an additional
URI has been defined.
When the new schema extends the permissible set of XML elements that may be the
target of some XML reference element errors may be encountered where RTA-RTE rejects the configuration since its internal validation engine is not aware of the change. In
cases where the reference element is not relevant to RTE generation this may be solved
by declaring the additional allowable destination elements in the RTE generator configuration file RTEGen.ini. For example to allow <PDU-REF> elements to additionally refer
to <GENERAL-PURPOSE-I-PDU> and <J-1939-DCM-I-PDU> elements:
[ReferenceValidationTags]
PDU-REF=GENERAL-PURPOSE-I-PDU,J-1939-DCM-I-PDU
4.1.2
Caching
By default, RTA-RTE uses the XML namespace to identify the schema to be used to
validate the input file. To support this RTA-RTE includes XSD caching to reduce load
time by reusing schemas when the same one is used for multiple input files.
The set of schemas to cache can be specified in the RTE generator configuration file
RTEGen.ini:
[ Schemas ]
XSD_0=.\Schemas\xml.xsd
Configuration
113
RTA-RTE V6.2.0
Reference Manual
XSD_1=.\Schemas\AUTOSAR_4-0-2.xsd
Alternatively the --xmlschema command-line option can be used to replace those
schema files specified in the configuration file. The option can be specified multiple
times to enable caching for more than one schema file.
When the --xmlschema command-line option is used any schemas specified
for caching in the RTE generator configuration file are ignored.
RTA-RTE selects a schema from the cache when the input file’s namespace matches the
target namespace of a schema present in the cache.
4.1.3
Entity Resolution
RTA-RTE uses the input files namespace to select a schema from the cache. In some
circumstances this approach may not be desired; for example, the AUTOSAR R4.2.1
and R4.2.2 schemas use identical namespaces and therefore cannot be distinguished
through this mechanism.
RTA-RTE includes the --xmlentity command-line option, which makes an association
between a system identifier and a schema file (.xsd). The result is that when RTARTE encounters a schemaLocation attribute in an XML file for the specified system
identifier, it redirects the XML parser to the schema in the corresponding .xsd file (as
specified on the command line) instead of using that from the schemaLocation.
For example, consider the following XML fragment which specifies that the schema is
located in the file AUTOSAR_4-0-1.xsd located in the current directory:
<?xml version="1.0" encoding="UTF-8"?>
<AUTOSAR ... xsi:schemaLocation=’http://autosar.org/schema/r4.0 AUTOSAR_4
-2-1.xsd’>
In the above example the system identifier from the schemaLocation is
“AUTOSAR_4-0-1.xsd”. The --xmlentity option can be used to redirect RTA-RTE’s XML
parser to a specific file.
--xmlentity=[AUTOSAR_4-0-1.xsd]c:\schemas\ar401.xsd
When using the --xmlentity option it is recommended to also disable schema caching
(see the --xmlschema command-line option). Otherwise the schema will be retained in
the XML parser’s cache and will be used to validate any additional input files with the
same namespace even if those files have different system identifiers.
AUTOSAR R4.x schemas include an XSD import of xml.xsd. It is therefore
recommended to specify the location of this XSD file using the same method
as for the R4.x schema itself.
114
Configuration
RTA-RTE V6.2.0
Reference Manual
4.2
References
Most elements within the input are named using the <SHORT-NAME> element so that
they can be referenced by other elements.
The short name is used to reference an element from another element. The short name
should be a valid C identifier—i.e. consist only of the characters ‘_’, ‘A-Z’, ‘a-z’ or ‘0-9’
(but not start with a ‘0-9’).
An element within an AUTOSAR configuration that has a short-name defines a namespace1 . All immediate descendant elements that are also named must have unique
names. This mechanism means that even if two objects contained within different parent objects have the same name it is possible to uniquely identify an individual object
using a reference that includes the name of the parent objects.
An absolute reference consists of one or more element short names separated by the
‘/’ character and preceded by a ‘/’ character. The reference string forms a path, much
like a file-system path, that can be used to unambiguously locate the target of the
reference. References may also be specified relative to a defined base package.
A reference never includes a trailing ‘/’ character.
The following subsections provide more information on absolute references, relative
references and instance references.
4.2.1
Absolute
An absolute reference starts with the ‘/’ character and unambiguously identifies the
target.
For example, consider an SWC type swcA within package A. An absolute reference to
the SWC type would be /A/swcA.
When following an absolute reference, RTA-RTE always starts searching at the top-most
package level. Thus the first element of an absolute reference must be the short-name
of an <AR-PACKAGE> element.
4.2.2
Relative
A relative reference can be distinguished from an absolute reference because the latter
always start with the ’/’ character, whereas the former does not. A relative reference
can only be understood in the context of a given base package.
Each AUTOSAR package may optionally define reference bases for other AUTOSAR
packages whose objects are referred to from objects within the package. Each reference base defines the prefix to be used for relative references that are associated with
the reference base. For example, assume a package defines the following reference
base:
<REFERENCE-BASE>
1
This should not be confused with an XML namespace.
Configuration
115
RTA-RTE V6.2.0
Reference Manual
<SHORT-LABEL>types</SHORT-LABEL>
<IS-DEFAULT>false</IS-DEFAULT>
<PACKAGE-REF DEST=’AR-PACKAGE’>/autosar_types</PACKAGE-REF>
</REFERENCE-BASE>
Subsequently within the package relative references can be used that are associated
with base “types”, for example, the relative reference within the package that defines
reference base “types” above:
<TYPE-TREF BASE=’types’>my_type</TYPE-TREF>
This is equivalent to the absolute reference:
<TYPE-TREF>/autosar_types/my_type</TYPE-TREF>
At most one reference base can be marked as the default for the package. The default reference base is used when a relative reference does not explicitly define the
associated base, e.g.:
<TYPE-TREF>my_type</TYPE-TREF>
4.2.3
Instance
An instance reference is a collection of absolute references that together define an
instance. When resolving an instance reference RTA-RTE resolves each absolute reference in turn until all encapsulated references have been processed.
The set of encapsulated references is dependent on context, for example an instance
reference from a “data received” event to a data element contains both a reference to
the required port and a reference to the data element within the interface categorizing
the port, for example:
<DATA-ELEMENT-IREF>
<R-PORT-PROTOTYPE-REF>...
<DATA-ELEMENT-PROTOTYPE-REF>...
</DATA-ELEMENT-IREF>
In contrast, a SWC instance reference contains an absolute reference to the top-level
composition, zero or more component prototype references (each of which references
one level of the composition hierarchy when nested compositions are used) and a final
target component prototype reference:
<COMPONENT-IREF>
<SOFTWARE-COMPOSITION-REF>...
<COMPONENT-PROTOTYPE-REF>...
<TARGET-COMPONENT-PROTOTYPE-REF>...
</COMPONENT-IREF>
The set of references necessary for each particular type of instance reference is specified whenever relevant in the following sections.
116
Configuration
RTA-RTE V6.2.0
Reference Manual
4.2.4
Referencing an ECU Instance
The --rte command line argument accepts a single argument identifying the starting
point of the RTE configuration. Usually this should be set to auto.
In some circumstances, e.g. if the supplied model is not an ECU Extract, then it is necessary to indicate a suitable starting point for the RTE configuration. In this case, the argument value can be a reference to an <ECU-INSTANCE> or <ECUC-VALUE-COLLECTION>
that references a system extract.
The reference must satisfy the following constraints:
• If referencing an <ECU-INSTANCE> then the reference must be an absolute reference to an ECU instance element and there must be exactly one ECU configuration
element in the input.
• If referencing an <ECUC-VALUE-COLLECTION> then the ECU configuration must contain an <ECU-EXTRACT-REF> that identifies the associated <SYSTEM> element as
well as references to the Rte, OS and COM configurations.
If the <SYSTEM> element has category “ECU_EXTRACT” then all component prototypes within the root software composition are used for RTE generation and any
SwcToEcuMappings present in the System element are ignored and can be omitted
if desired.
Otherwise the <SYSTEM> element must contain exactly one <SWC-TO-ECU-MAPPING>
element that references the associated <ECU-INSTANCE>.
The --rte option can be passed a parameter of “auto” to cause the RTE generator
to search for and use the single EcucValueCollection present in the input.
4.3
Packages
The configuration of software-components, types, ECUs, etc. within an AUTOSAR configuration is contained within one or more AUTOSAR package elements.
A package element, specified using the <AR-PACKAGE> tag, can contain either one or
more sub-packages or one or more elements. Since sub-packages can contain AUTOSAR packages the relationship is recursive and a hierarchical tree of packages—akin
to a file system—can be constructed.
The <AUTOSAR> element is the XML root node and must be present in all input files.
Within the <TOP-LEVEL-PACKAGES> node one or more AUTOSAR packages can be defined. Each AUTOSAR package defines either sub-packages or elements.
ar_package ::=
<AR-PACKAGE>
short_name
( elements )
( sub-packages)
</AR-PACKAGE>
Configuration
117
RTA-RTE V6.2.0
Reference Manual
Each <SUB-PACKAGES> element defines one or more AUTOSAR packages. They contain AUTOSAR sub-packages, which can themselves define either elements or further
<SUB-PACKAGES>.
sub_packages ::=
<SUB-PACKAGES>
+ ar_package
</SUB-PACKAGES>
An AUTOSAR package can contain both sub-packages and elements.
The + in the above XML indicates there can be one or more of the items appearing next
to the +.
4.3.1
Package Merging
An AUTOSAR package is an open set and therefore the RTA-RTE RTE generator “merges”
elements (SWC types, interfaces, etc˙) and containers (OS tasks, runnable entity mappings, etc˙) within packages with the same name when the XML files are loaded.
The merge rules implemented by RTA-RTE depend on the file type:
ECU Configuration —The ECU Configuration defines the OS and RTE configuration for
an ECU in terms of multiple <CONTAINER> elements each of which describes one
aspect of the configuration such as a task or runnable entity mapping.
Containers can be split across multiple files and those with the same name at the
same location within the package hierarchy merged when loaded.
Model —The model includes all SWC type definitions, system elements, etc.
The atpSplitable pattern is specified by AUTOSAR on certain aggregations. Not
all of these are supported by RTA-RTE; in most cases two elements with the same
path are regarded as a collision. However RTA-RTE does support merging for the
following application configuration elements:
• <MODULE-CONFIGURATION>
• <ECU-CONFIGURATION>
• <SYSTEM>
• <COMPOSITION-TYPE>
Note that subelements of splitable model elements, such as SWC mappings, cannot typically be split and must be uniquely named.
The merging of elements and containers is illustrated in Figure 4.1.
4.4
Software Components
Atomic software component types are defined using one of the following tags:
118
Configuration
RTA-RTE V6.2.0
Reference Manual
root
root
pkgA
El1
pkgB
El2
El1
pkgB
El2
El3
merge
pkgC
El4
El1
El2
merge
root
pkgB
pkgA
El1
El2
El1
El2
pkgC
El3
El4
El1
El2
Figure 4.1: AUTOSAR Package Merge
• <APPLICATION-SW-COMPONENT-TYPE> — component that is part of an AUTOSAR application.
• <SENSOR-ACTUATOR-SW-COMPONENT-TYPE> — A component that is part of an AUTOSAR application and accesses sensors and/or actuators.
• <SERVICE-SW-COMPONENT-TYPE>.
• <ECU-ABSTRACTION-COMPONENT-TYPE>
• <COMPLEX-DEVICE-DRIVER-SW-COMPONENT-TYPE>
Whichever tag is used to declare a software component type, the element defines two
things: the component’s type name (necessary so that it can be referenced) and the
component’s port prototypes.
component_type ::=
( <APPLICATION-SW-COMPONENT-TYPE>
| <SENSOR-ACTUATOR-SW-COMPONENT-TYPE>
| <SERVICE-SW-COMPONENT-TYPE>
| <ECU-ABSTRACTION-SW-COMPONENT-TYPE>
Configuration
119
RTA-RTE V6.2.0
Reference Manual
| <COMPLEX-DEVICE-DRIVER-SW-COMPONENT-TYPE>
| <NV-BLOCK-SW-COMPONENT-TYPE> )
short_name
port_prototypes
nv_block_descriptors
( </APPLICATION-SW-COMPONENT-TYPE>
| </SENSOR-ACTUATOR-SW-COMPONENT-TYPE>
| </SERVICE-SW-COMPONENT-TYPE>
| </ECU-ABSTRACTION-SW-COMPONENT-TYPE>
| </COMPLEX-DEVICE-DRIVER-SW-COMPONENT-TYPE>
| </NV-BLOCK-SW-COMPONENT-TYPE> )
The opening and closing tags for a component_type definition must match.
4.4.1
Port Prototypes
Port prototypes are defined using either the <P-PORT-PROTOTYPE> or
<R-PORT-PROTOTYPE> element depending on whether the containing softwarecomponent type provides or requires the port. All port prototypes, whether they are
required or provided, are encapsulated within a <PORTS> element:
port_prototypes ::=
<PORTS>
+ port_prototype
</PORTS>
A port prototype defines either a required port or a provided port; a port cannot be
both required and provided.
port_prototype ::=
( r_port_prototype | p_port_prototype )
A port prototype is named and the name is used to reference instances of the port
prototype once the containing software component has been instantiated.
r_port_prototype ::=
<R-PORT-PROTOTYPE>
short_name
( communication_specification )
required_interface_reference
</R-PORT-PROTOTYPE>
p_port_prototype ::=
<P-PORT-PROTOTYPE>
short_name
( communication_specification )
provided_interface_reference
</P-PORT-PROTOTYPE>
120
Configuration
RTA-RTE V6.2.0
Reference Manual
Each port prototype definition contains a reference to a categorizing interface, which
can be a sender-receiver interface, client-server interface, a calibration interface, a
mode switch interface or an Nv-data interface.
Multiple port prototypes, even if located in different software components, can reference the same interface.
required_interface_reference ::=
<REQUIRED-INTERFACE-TREF>
ref
</REQUIRED-INTERFACE-TREF>
provided_interface_reference ::=
<PROVIDED-INTERFACE-TREF>
ref
</PROVIDED-INTERFACE-TREF>
4.4.2
NV Blocks
AUTOSAR R4.0 introduced the <NV-BLOCK-SW-COMPONENT-TYPE> SWC type (Section 4.4).
An NvBlockSwComponentType SWC can declare one or more
<NV-BLOCK-DESCRIPTOR> elements that enable configuration and access to mirrors of
data managed by the AUTOSAR NVRAM manager.
The NvBlockDescriptor elements
<NV-BLOCK-DESCRIPTORS> element.
are
declared
within
an
encapsulating
nv_block_descriptors ::=
<NV-BLOCK-DESCRIPTORS>
+ nv_block_descriptor
</NV-BLOCK-DESCRIPTORS>
nv_block_descriptor ::=
<NV-BLOCK-DESCRIPTOR>
short_name
( cs_ports )
( nvblock_data_mappings )
ram_block
( rom_block )
</NV-BLOCK-DESCRIPTOR>
Each NvBlockDescriptor element declares a ram block.
ram_block ::=
<RAM-BLOCK>
short_name
( sw_addr_method_ref )
type_ref
( init_value )
</RAM-BLOCK>
Configuration
121
RTA-RTE V6.2.0
Reference Manual
The <RAM-BLOCK> serves as the RAM mirror for the NVRAM manager’s non-volatile data.
The element is named and can therefore be referenced by other elements within the
configuration.
RTA-RTE uses the ram-block element’s short_name as part of the created instance and therefore it must be unique within the context of the
NvBlockSwComponentType.
In addition to the ram-block, each NvBlockDescriptor element can optionally declare
a rom-block, which can be used for initializing the ram-block.
rom_block ::=
<ROM-BLOCK>
short_name
type_ref
init_value
</ROM-BLOCK>
The types used by the ram-block and rom-block must be compatible. RTA-RTE does not
apply data conversion when initializing the ram-block from the rom-block.
The configuration of cs_ports and nvblock_data_mappings is considered in detail in
Section 4.8.
4.4.3
Communication Specification
The communication_specification element (ComSpec) defines additional attributes of a
port-prototype. For example:
• For a server, the queue length
• For a sender, whether or not transmission acknowledgment is enabled.
ComSpecs for Servers, ModeSwitchSenders and QueuedReceivers are mandatory. They
must have a queue length greater than zero, and this is enforced by RTA-RTE.
communication_specification ::=
( provided_com_spec | required_com_spec )
provided_com_spec ::=
<PROVIDED-COM-SPECS>
( server_com_spec
| sender_com_spec
| modemanager_com_spec
| parameter_provide_com_spec )
</PROVIDED-COM-SPECS>
required_com_spec ::=
<REQUIRED-COM-SPECS>
( receiver_com_spec
| client_com_spec
| parameter_require_com_spec )
</REQUIRED-COM-SPECS>
122
Configuration
RTA-RTE V6.2.0
Reference Manual
Sender
A data sender can be optionally configured to provide:
• An acknowledgment when a transmission is complete.
• An initial value to be used when the data is transmitted before it is written.
• Enabling (or disabling) data invalidation.
Transmission Acknowledgement
Acknowledgment is enabled using the PROVIDED-COM-SPECS element defined within the
providing port prototype.
sender_com_spec ::=
( event_sender_com_spec | data_sender_com_spec )
Both event and data sender com specs define whether or not transmission acknowledgment is required and the data element to be acknowledged. In addition, a com spec
element for a data sender can define whether or not the datum can be invalidated.
event_sender_com_spec ::=
<QUEUED-SENDER-COM-SPEC>
<DATA-ELEMENT-REF>ref</DATA-ELEMENT-REF>
( ack_request )
</QUEUED-SENDER-COM-SPEC>
data_sender_com_spec ::=
<NONQUEUED-SENDER-COM-SPEC>
<DATA-ELEMENT-REF>ref</DATA-ELEMENT-REF>
( ack_request )
( invalidation_specification )
( init_value_specification )
</NONQUEUED-SENDER-COM-SPEC>
Communication specifications for queued and non-queued ports both include a
<DATA-ELEMENT-REF> reference that defines the data element to which this communication specification applies.
Both queued and non-queued communication specifications can optionally define one
or more transmission acknowledgment request(s):
ack_request ::=
<TRANSMISSION-ACKNOWLEDGE>
<TIMEOUT>float</TIMEOUT>
</TRANSMISSION-ACKNOWLEDGE>
A non-queued sender can optionally provide an initial value to be used when transmitting the data (e.g. in a network frame) before it has been updated by the application.
Configuration
123
RTA-RTE V6.2.0
Reference Manual
init_value_specification ::=
<INIT-VALUE-REF>
ref
</INIT-VALUE-REF>
The <INIT-VALUE-REF> reference defines the constant to be used for the data element’s initial value. The reference should identify the constant’s value specification
and not the constant specification element itself.
RTA-RTE uses AUTOSAR COM for inter-ECU communication. AUTOSAR COM
supports initial values only for integer types and therefore RTA-RTE will raise
an error if an initial value is specified for another type.
A non-queued data sender can optionally enable or disable data invalidation using the
<CAN-INVALIDATE> element. If omitted the default is to disable data invalidation.
invalidation_specification ::=
<CAN-INVALIDATE>( true | false )</CAN-INVALIDATE>
The “invalid value” used when a data item is invalidated is set within the type specification.
Mode Manager
A mode manager can be optionally configured to provide:
• An acknowledgment when a mode switch is complete.
• The length of the queue for mode switch requests.
Both the enabling of acknowledgment and the queue length are enabled using
the <MODE-SWITCH-COM-SPEC> element defined within the providing port prototype’s
<PROVIDED-COM-SPEC>.
A ModeSwitchSenderComSpec must have a queue length greater than zero, and this is
enforced by RTA-RTE.
modemanager_com_spec ::=
<MODE-SWITCH-COM-SPEC>
( mode_ack_timeout )
( mode_switch_queuesize )
</MODE-SWITCH-COM-SPEC>
Mode switch acknowledgment is enabled by the specification of a <TIMEOUT> element
within the <MODE-SWITCHED-ACK>:
mode_ack_timeout ::=
<MODE-SWITCHED-ACK>
<TIMEOUT>time</TIMEOUT>
</MODE-SWITCHED-ACK>
124
Configuration
RTA-RTE V6.2.0
Reference Manual
The time specified within the <MODE-SWITCHED-ACK> determines the timeout applied
when the Rte_Feedback API is invoked; if no switch occurs within the specified timeout
then runnable entities associated with the acknowledgment are activated.
A timeout specification of 0 enables acknowledgment without a timeout.
The length of the queue for mode switch requests is enabled by the specification of a
<QUEUE-LENGTH> element within the <MODE-SWITCH-COM-SPEC> element:
mode_switch_queuesize ::=
<QUEUE-LENGTH>int</QUEUE-LENGTH>
A queue length of zero is invalid.
Mode user
A mode user can request asynchronous mode switch using a <REQUIRED-COM-SPECS>
element defined within the providing component prototype.
server_com_spec ::=
<MODE-SWITCH-RECEIVER-COM-SPEC>
support_async_modeswitch
</MODE-SWITCH-RECEIVER-COM-SPEC>
support_async_modeswitch ::=
<SUPPORTS-ASYNCHRONOUS-MODE-SWITCH>
boolean
</SUPPORTS-ASYNCHRONOUS-MODE-SWITCH>
All mode users must explicitly enable asynchronous mode switch for it to
take effect. No warning is issued if a subset of mode users enable asynchronous mode switch.
Parameter Provide
A parameter provider com spec can be optionally configured to provide initial values
for calibration parameters. A calibration com-spec contains a pair of values; the first is
a reference to a constant containing the initial value and the second a reference to the
associated calibration prototype:
parameter_provide_com_spec ::=
<PARAMETER-PROVIDE-COM-SPEC>
init_value
<PARAMETER-REF>ref</PARAMETER-REF>
</PARAMETER-PROVIDE-COM-SPEC>
The referenced calibration parameter must be defined within the interface categorizing
the port. The referenced constant and the calibration parameter must have the same
underlying type.
Configuration
125
RTA-RTE V6.2.0
Reference Manual
Parameter Require
A parameter requirer com spec can be optionally configured to provide initial values for
calibration parameters for unconnected require ports.
Parameter require com specs are only used for unconnected RPorts.
A calibration com-spec contains a pair of values; the first is a reference to a constant
containing the initial value and the second a reference to the associated calibration
prototype:
parameter_require_com_spec ::=
<PARAMETER-REQUIRE-COM-SPEC>
init_value
<PARAMETER-REF>ref</PARAMETER-REF>
</PARAMETER-REQUIRE-COM-SPEC>
The referenced calibration parameter must be defined within the interface categorizing
the port. The referenced constant and the calibration parameter must have the same
underlying type.
Receiver
A receiver can use either ‘data’ (non-queued) or ‘event’ (queued) semantics. The
<REQUIRED-COM-SPECS> element can contain a communication specification for either
a ‘data’ or an ‘event’ receiver.
receiver_com_spec ::=
( event_receiver_com_spec
| data_receiver_com_spec )
Event (Queued) Receivers
A ’QUEUED’ receiver com_spec is used whenever a data element within the interface
categorizing the port is specified as using queued reception.
event_receiver_com_spec ::=
<QUEUED-RECEIVER-COM-SPEC>
<DATA-ELEMENT-REF>ref</DATA-ELEMENT-REF>
( filter )
( queue_length )
</QUEUED-RECEIVER-COM-SPEC>
Queue Length
A ‘QUEUED’ receiver can configure the length of the queue used to hold received
data before it is processed. The queue length is set for each received data element using the using queue_length within the <EVENT-RECEIVER-COM-SPECS> or
<QUEUED-RECEIVER-COM-SPECS> element.
A QueuedReceiverComSpec must have a queue length greater than zero, and this is
enforced by RTA-RTE.
126
Configuration
RTA-RTE V6.2.0
Reference Manual
queue_length ::=
<QUEUE-LENGTH>integer</QUEUE-LENGTH>
Data (Non-Queued) Receivers
A ‘non-queued’ receiver com_spec is used whenever a data element within the interface categorizing the port is specified as using non-queued reception.
data_receiver_com_spec ::=
<UNQUEUED-RECEIVER-COM-SPEC>
<DATA-ELEMENT-REF>ref</DATA-ELEMENT-REF>
( alive_timeout )
( filter )
( init_value_specification )
( invalid_data_handling )
</UNQUEUED-RECEIVER-COM-SPEC>
For
both
the
‘queued’
and
‘non-queued’
receiver
specifications
the
<DATA-ELEMENT-IREF> instance reference defines the data element to which this
communication specification applies and requires a single context reference (the
port prototype within the software-component type) and a target reference (the data
element within the interface that categorizes the port prototype).
A ‘non-queued’ receiver can be optionally configured to define:
• The timeout used to verify that the sender is “alive”.
• An initial value to be used when the data is transmitted before it is written.
• The method to be used to handle invalidated data. If invalidation is enabled, the
RTE generator will respond to invalid data it encounters by using either the method
of “keep” or that of “replace”.
• A filter applied to received values by the generated RTE before they are forwarded
to the receiver.
Alive Timeout
A ‘non-queued’ receiver can optionally configure the minimum acceptable inter-arrival
period for signals received via COM.
alive_timeout ::=
<ALIVE-TIMEOUT>time</ALIVE-TIMEOUT>
If a non-zero “alive timeout” is specified and the inter-arrival period drops below the
specified value then any user-configured DataReceiveErrorEvent will be raised.
Alive timeout applies only to inter-ECU communication.
Configuration
127
RTA-RTE V6.2.0
Reference Manual
Initial Value
A ‘non-queued’ receiver can optionally provide an initial value to be used when the data
is read before a value has been received from the sender. If omitted the default is to
disable data invalidation.
init_value_specification ::=
<INIT-VALUE-REF>ref</INIT-VALUE-REF>
The <INIT-VALUE-REF> reference defines the constant that defines the data element’s
initial value. The reference should identify a constant’s value specification and not to
the constant specification element itself.
RTA-RTE uses AUTOSAR COM for inter-ECU communication. AUTOSAR COM
supports initial values only for integer types and therefore RTA-RTE will raise
an error if an initial value is specified for another type.
Invalidation
The actions taken when a receiver receives invalid data can be set using the
<HANDLE-INVALID> element. This can be either “keep” to retain the invalid value and
pass it to the receiver or “replace” to substitute the data’s initial value.
invalid_data_handling ::=
<HANDLE-INVALID>(KEEP|REPLACE)</HANDLE-INVALID>
Filter
Finally a receiver can configure a filter that is applied to values before they are passed
to the receiver.
filter ::=
<FILTER>filter_condition</FILTER>
A wide range of filter conditions are available:
filter_condition ::=
( ALWAYS
| MASKED-NEW-DIFFERS-MASKED-OLD
| MASKED-NEW-DIFFERS-X
| MASKED-NEW-EQUALS-MASKED-OLD
| MASKED-NEW-EQUALS-X
| NEVER
| NEW-IS-DIFFERENT
| NEW-IS-EQUAL
| NEW-IS-GREATER
| NEW-IS-GREATER-OR-EQUAL
| NEW-IS-LESS
| NEW-IS-LESS-OR-EQUAL
| NEW-IS-OUTSIDE
| NEW-IS-WITHIN
| ONE-EVERY-N )
The available filter conditions are summarized in the following table.
128
Configuration
RTA-RTE V6.2.0
Reference Manual
Condition Description
Masked new value differs
from masked old value.
Masked new value differs
from X.
Masked new value equals
masked previous value.
XML
<MASKED-NEW-DIFFERS-MASKED-OLD>
<MASK>int</MASK>
</MASKED-NEW-DIFFERS-MASKED-OLD>
<MASKED-NEW-DIFFERS-X>
<MASK>int</MASK>
<X>int</X>
</MASKED-NEW-DIFFERS-X>
<MASKED-NEW-EQUALS-MASKED-OLD>
<MASK>int</MASK>
</MASKED-NEW-EQUALS-MASKED-OLD>
Masked new value equals X.
<MASKED-NEW-EQUALS-X>
<MASK>int</MASK>
<X>int</X>
</MASKED-NEW-EQUALS-X>
New value is different from
previous value.
New value is equal to previous value.
New value is greater than
previous.
New value is greater than or
equal to previous.
<NEW-IS-DIFFERENT>
</NEW-IS-DIFFERENT>
<NEW-IS-EQUAL>
</NEW-IS-EQUAL>
<NEW-IS-GREATER>
</NEW-IS-GREATER>
<NEW-IS-GREATER-OR-EQUAL>
</NEW-IS-GREATER-OR-EQUAL>
Configuration
129
RTA-RTE V6.2.0
Reference Manual
Condition Description
New value is less than previous.
New value is less than or
equal to previous.
New value is outside specified range.
New value is within specified
range.
XML
<NEW-IS-LESS>
</NEW-IS-LESS>
<NEW-IS-LESS-OR-EQUAL>
</NEW-IS-LESS-OR-EQUAL>
<NEW-IS-OUTSIDE>
<MIN>int</MIN>
<MAX>int</MAX>
</NEW-IS-OUTSIDE>
<NEW-IS-WITHIN>
<MIN>int</MIN>
<MAX>int</MAX>
</NEW-IS-WITHIN>
Table 4.2: Supported Signal Conditions for Value-based Filtering
Client
The “client” communication specification is a place-holder—it does not specify any information used by RTA-RTE.
Server
A non re-entrant server contains a queue used to hold client requests before they
are processed by the server. The queue length is set for each server using the
<PROVIDED-COM-SPECS> element defined within the providing component prototype.
130
Configuration
RTA-RTE V6.2.0
Reference Manual
4.5
AUTOSAR Types and Data Conversion
4.5.1
ApplicationPrimitiveDataType
An ApplicationPrimitiveDataType allows the modelling of a single data value relevant to a SWCT in terms of physical quantities, without the modeller having to decide
on the implementation details of the type, such as the width, signedness and encoding.
The choice of representation for the quantity can then be made later in the development cycle.
application_primitive_data_type ::=
<APPLICATION-PRIMITIVE-DATA-TYPE>
short_name
<CATEGORY>VALUE</CATEGORY>
<SW-DATA-DEF-PROPS>
<SW-DATA-DEF-PROPS-VARIANTS>
<SW-DATA-DEF-PROPS-CONDITIONAL>
<SW-CALIBRATION-ACCESS>sw_calibration_access</SWCALIBRATION-ACCESS>
( <COMPU-METHOD-REF DEST=’COMPU-METHOD’>ref</COMPUMETHOD-REF> )
( <UNIT-REF>ref</UNIT-REF> )
</SW-DATA-DEF-PROPS-CONDITIONAL>
</SW-DATA-DEF-PROPS-VARIANTS>
</SW-DATA-DEF-PROPS>
</APPLICATION-PRIMITIVE-DATA-TYPE>
The ShortName of an ApplicationPrimitiveDataType is only used to identify the
model element. An ApplicationPrimitiveDataType does not result in a C type
in the generated code for the RTE. Instead, every ApplicationDataType that is
used in the model must, by the RTE generation time, be mapped to a compatible ImplementationDataType (see 4.5.15 DataTypeMappingSet) that will be used in
the generated code to represent the physical quantity (or quantities, for complex
ApplicationDataTypes, see below) using the chosen encoding.
Category must contain the literal text VALUE.
CompuMethodRef references a CompuMethod that describes how this ApplicationDataType relates to the physical world (CompuMethod of Category IDENTICAL or
LINEAR). (See 4.5.11 CompuMethod).
UnitRef is optional because it is possible that the CompuMethod references a Unit. If
the CompuMethod references a Unit then the ApplicationPrimitiveDataType must
• not reference any Unit, or
• reference the same Unit (same path), or
• reference an exactly similar Unit (different path to a Unit with same relevant properties).
Configuration
131
RTA-RTE V6.2.0
Reference Manual
When Interfaces containing ApplicationDataTypes are connected by a connector that references a PortInterfaceMapping then the Data Conversion feature is
activated (see the User Guide) for an ApplicationPrimitiveDataType or for the
ApplicationPrimitiveDataTypes within a complex ApplicationDataType.
4.5.2
ApplicationRecordDataType
An ApplicationRecordDataType is a compound data type describing a group of values
in the physical world, analogous to a C struct.
application_record_data_type ::=
<APPLICATION-RECORD-DATA-TYPE>
short_name
<CATEGORY>STRUCTURE</CATEGORY>
<SW-DATA-DEF-PROPS>
<SW-DATA-DEF-PROPS-VARIANTS>
<SW-DATA-DEF-PROPS-CONDITIONAL>
<SW-CALIBRATION-ACCESS>sw_calibration_access</SWCALIBRATION-ACCESS>
</SW-DATA-DEF-PROPS-CONDITIONAL>
</SW-DATA-DEF-PROPS-VARIANTS>
</SW-DATA-DEF-PROPS>
<ELEMENTS>
(
<APPLICATION-RECORD-ELEMENT>
short_name
<CATEGORY>category</CATEGORY>
<TYPE-TREF DEST=’dest’>ref</TYPE-TREF>
</APPLICATION-RECORD-ELEMENT>
... )
</ELEMENTS>
</APPLICATION-RECORD-DATA-TYPE>
As for ApplicationPrimitiveDataType, the ShortName is only used to identify the model
element and no C type in the generated code results. Instead a DataTypeMappingSet
(see 4.5.15) is required to specify a mapping to an ImplementationDataType of category STRUCTURE. Likewise the element ShortName is only used to identify the model
element and does not influence any generated C code.
Category must contain the literal text STRUCTURE.
Each element can be an ApplicationPrimitiveDataType, ApplicationRecordDataType or
ApplicationArrayDataType. The element Category and the reference Dest should match
the class of the referenced data type.
4.5.3
ApplicationArrayDataType
An ApplicationArrayDataType is a compound data type describing a group of values in
the physical world of the same type, analogous to a C array.
application_array_data_type ::=
<APPLICATION-ARRAY-DATA-TYPE>
132
Configuration
RTA-RTE V6.2.0
Reference Manual
short_name
<CATEGORY>ARRAY</CATEGORY>
<SW-DATA-DEF-PROPS>
<SW-DATA-DEF-PROPS-VARIANTS>
<SW-DATA-DEF-PROPS-CONDITIONAL>
<SW-CALIBRATION-ACCESS>sw_calibration_access</SWCALIBRATION-ACCESS>
</SW-DATA-DEF-PROPS-CONDITIONAL>
</SW-DATA-DEF-PROPS-VARIANTS>
</SW-DATA-DEF-PROPS>
<ELEMENT>
short_name
<CATEGORY>category</CATEGORY>
<TYPE-TREF DEST=’dest’>ref</TYPE-TREF>
<ARRAY-SIZE-SEMANTICS>FIXED-SIZE</ARRAY-SIZE-SEMANTICS>
<MAX-NUMBER-OF-ELEMENTS>int</MAX-NUMBER-OF-ELEMENTS>
</ELEMENT>
</APPLICATION-ARRAY-DATA-TYPE>
As for ApplicationPrimitiveDataType, the ShortName is only used to identify the model
element and no C type in the generated code results. Instead a DataTypeMappingSet
(see 4.5.15) is required to specify a mapping to an ImplementationDataType of category ARRAY. Likewise the element ShortName is only used to identify the model element and does not influence any generated C code.
Category must contain the literal text ARRAY. RTA-RTE does not support dynamic arrays
so ArraySizeSemantics must be the literal text FIXED-SIZE.
The element type can be an ApplicationPrimitiveDataType, ApplicationRecordDataType
or ApplicationArrayDataType. The element Category and the reference Dest should
match the class of the referenced data type.
4.5.4
ImplementationDataType — General
An
ImplementationDataType
describes
a
C
type.
Typically,
an
ImplementationDataType results in a typedef being written to the generated
code (but see 4.5.5).
All ImplementationDataTypes contain a ShortName and a Category. The ShortName of
an ImplementationDataType becomes the name of the C type in the generated code.
The rules about what other sub-elements may be configured change according to the
Category supplied.
implementation_data_type::=
( implementation_data_type_type_reference
| implementation_data_type_value
| implementation_data_type_array
| implementation_data_type_structure )
Configuration
133
RTA-RTE V6.2.0
Reference Manual
4.5.5
TypeEmitter
In AUTOSAR 3.x and early 4.x, ImplementationDataTypes that reference a SwBaseType
result in a typedef only if the corresponding SwBaseType.nativeDeclaration is not
empty. For ImplementationDataTypes that are defined in external header files, the
nativeDeclaration should be empty in order to suppress generation of a definition by
RTA-RTE that might conflict with the externally-supplied definition.
From AUTOSAR 4.0.3, ImplementationDataTypes contain a typeEmitter attribute. If
the attribute is present and its value is RTE then RTA-RTE will generate the corresponding typedef for the type. If the typeEmitter is present but has a value other than RTE,
then RTA-RTE assumes that the type is defined somewhere in a header file outside of
RTA-RTE’s control and does not generate a typedef.
Additionally, in AUTOSAR 4.x, if the typeEmitter attribute is not present, then RTA-RTE
uses the legacy method in which the presence or absence of nativeDeclaration is
used to decide.
4.5.6
ImplementationDataType — Category TYPE_REFERENCE
An ImplementationDataType of Category TYPE_REFERENCE expresses a C type that is
an alias for another C type.
<IMPLEMENTATION-DATA-TYPE>
short_name
<CATEGORY>TYPE_REFERENCE</CATEGORY>
<SW-DATA-DEF-PROPS>
<SW-DATA-DEF-PROPS-VARIANTS>
<SW-DATA-DEF-PROPS-CONDITIONAL>
<SW-ADDR-METHOD-REF DEST="SW-ADDR-METHOD">ref</SW-ADDRMETHOD-REF>
<IMPLEMENTATION-DATA-TYPE-REF DEST=’IMPLEMENTATION-DATA
-TYPE’>ref</IMPLEMENTATION-DATA-TYPE-REF>
<INVALID-VALUE>int</INVALID-VALUE>
</SW-DATA-DEF-PROPS-CONDITIONAL>
</SW-DATA-DEF-PROPS-VARIANTS>
</SW-DATA-DEF-PROPS>
<TYPE-EMITTER>RTE</TYPE-EMITTER>
</IMPLEMENTATION-DATA-TYPE>
If used in the RTE then it is expressed in the generated code as:
typedef type-specifier typedef-name;
The ShortName of ImplementationDataType becomes typedef-name.
The referenced ImplementationDataType represents the type-specifier in the typedef.
This means that the ShortName of the referenced type becomes type-specifier.
The recommended way to define new ImplementationDataTypes that represent simple values is to set Category to TYPE_REFERENCE and reference a Platform Type in ImplementationDataTypeRef. The Platform Types are defined by AUTOSAR and help to
134
Configuration
RTA-RTE V6.2.0
Reference Manual
protect the model from differences between hardware targets. (See AUTOSAR Specification of Platform Types).
<IMPLEMENTATION-DATA-TYPE>
<SHORT-NAME>myImplType</SHORT-NAME>
<CATEGORY>TYPE_REFERENCE</CATEGORY>
<SW-DATA-DEF-PROPS>
<SW-DATA-DEF-PROPS-VARIANTS>
<SW-DATA-DEF-PROPS-CONDITIONAL>
<IMPLEMENTATION-DATA-TYPE-REF DEST=’IMPLEMENTATION-DATATYPE’>/AUTOSAR_PlatformTypes/ImplementationDataTypes/
uint16</IMPLEMENTATION-DATA-TYPE-REF>
</SW-DATA-DEF-PROPS-CONDITIONAL>
</SW-DATA-DEF-PROPS-VARIANTS>
</SW-DATA-DEF-PROPS>
<TYPE-EMITTER>RTE</TYPE-EMITTER>
</IMPLEMENTATION-DATA-TYPE>
typedef uint16 myImplType;
Note that an ImplementationDataTypeElement of Category TYPE_REFERENCE has a
different meaning. See 4.5.8 ImplementationDataType — Category ARRAY and 4.5.9
ImplementationDataType — Category STRUCTURE.
4.5.7
ImplementationDataType — Category VALUE
An ImplementationDataType of category VALUE describes a simple C data type.
<IMPLEMENTATION-DATA-TYPE>
short_name
<CATEGORY>VALUE</CATEGORY>
<SW-DATA-DEF-PROPS>
<SW-DATA-DEF-PROPS-VARIANTS>
<SW-DATA-DEF-PROPS-CONDITIONAL>
<BASE-TYPE-REF DEST=’SW-BASE-TYPE’>ref</BASE-TYPE-REF>
<DATA-CONSTR-REF DEST=’DATA-CONSTR’>ref</DATA-CONSTR-REF>
</SW-DATA-DEF-PROPS-CONDITIONAL>
</SW-DATA-DEF-PROPS-VARIANTS>
</SW-DATA-DEF-PROPS>
<TYPE-EMITTER>RTE</TYPE-EMITTER>
</IMPLEMENTATION-DATA-TYPE>
If used in the RTE then the C type is expressed in the generated code as:
typedef type-specifier typedef-name;
Note: Normally you should use Category TYPE_REFERENCE for this purpose as types
defined in that way are more easily portable between hardware targets.
The ShortName of ImplementationDataType becomes typedef-name.
BaseTypeRef references a SwBaseType that specifies the width of the type in bits and
the encoding (which defines whether or not the type is signed). The SwBaseType’s
Configuration
135
RTA-RTE V6.2.0
Reference Manual
nativeDeclaration contains native C that will be emitted as the type-specifier in the
typedef. If the nativeDeclaration is blank or missing then no typedef is emitted.
[rte_sws 7104 in, e.g. AUTOSAR_SWS_RTE R3.1.0]
In the case of an ImplementationDataTypeElement (See 4.5.8 ImplementationDataType — Category ARRAY and 4.5.9 ImplementationDataType — Category STRUCTURE) no typedef is emitted.
An ImplementationDataTypeElement of Category VALUE is only rarely required (better to use TYPE_REFERENCE). If such an
ImplementationDataTypeElement is used then its referenced SwBaseType must have a
valid nativeDeclaration. If the nativeDeclaration is missing or blank then RTA-RTE
rejects the configuration, because a member of the complex type has no type-specifier:
typedef struct {
uint8 element1;
/* using a TYPE_REFERENCE to Platform
Type uint8 */
unsigned char element2; /* with nativeDeclaration "unsigned char
". Fails MISRA 6.3. */
/*ERROR*/ element3;
/* using a VALUE referencing a
SwBaseType without a nativeDeclaration */
} myStructType;
4.5.8
ImplementationDataType – Category ARRAY
An ImplementationDataType of category ARRAY describes a C array data type.
<IMPLEMENTATION-DATA-TYPE>
short_name
<CATEGORY>ARRAY</CATEGORY>
<SUB-ELEMENTS>
<IMPLEMENTATION-DATA-TYPE-ELEMENT>
short_name
<CATEGORY>TYPE_REFERENCE</CATEGORY>
<ARRAY-SIZE>int</ARRAY-SIZE>
<ARRAY-SIZE-SEMANTICS>FIXED-SIZE</ARRAY-SIZE-SEMANTICS>
<SW-DATA-DEF-PROPS>
<SW-DATA-DEF-PROPS-VARIANTS>
<SW-DATA-DEF-PROPS-CONDITIONAL>
<IMPLEMENTATION-DATA-TYPE-REF DEST=’
IMPLEMENTATION-DATA-TYPE’>ref</
IMPLEMENTATION-DATA-TYPE-REF>
</SW-DATA-DEF-PROPS-CONDITIONAL>
</SW-DATA-DEF-PROPS-VARIANTS>
</SW-DATA-DEF-PROPS>
</IMPLEMENTATION-DATA-TYPE-ELEMENT>
</SUB-ELEMENTS>
<TYPE-EMITTER>RTE</TYPE-EMITTER>
</IMPLEMENTATION-DATA-TYPE>
If used in the RTE then the C type is expressed in the generated code as:
typedef type-specifier typedef-name [ constant ];
136
Configuration
RTA-RTE V6.2.0
Reference Manual
The ShortName of the ImplementationDataType becomes typedef-name.
The ArraySize of the ImplementationDataTypeElement becomes constant.
The ShortName of the ImplementationDataTypeElement is not used except to identify
the configuration element.
The ImplementationDataTypeElement specifies the type of the array element, which
in turn can be of Category TYPE_REFERENCE, VALUE, STRUCTURE or ARRAY.
4.5.9
ImplementationDataType — Category STRUCTURE
An ImplementationDataType of category STRUCTURE describes a C struct data type.
<IMPLEMENTATION-DATA-TYPE>
short_name
<CATEGORY>STRUCTURE</CATEGORY>
<SUB-ELEMENTS>
(
<IMPLEMENTATION-DATA-TYPE-ELEMENT>
short_name
<CATEGORY>TYPE_REFERENCE</CATEGORY>
<SW-DATA-DEF-PROPS>
<SW-DATA-DEF-PROPS-VARIANTS>
<SW-DATA-DEF-PROPS-CONDITIONAL>
<IMPLEMENTATION-DATA-TYPE-REF DEST=’IMPLEMENTATIONDATA-TYPE’>ref</IMPLEMENTATION-DATA-TYPE-REF>
</SW-DATA-DEF-PROPS-CONDITIONAL>
</SW-DATA-DEF-PROPS-VARIANTS>
</SW-DATA-DEF-PROPS>
</IMPLEMENTATION-DATA-TYPE-ELEMENT>
... )
</SUB-ELEMENTS>
<TYPE-EMITTER>RTE</TYPE-EMITTER>
</IMPLEMENTATION-DATA-TYPE>
If used in the RTE then the C type is expressed in the generated code as:
typedef struct {
member-type-specifier member-name;
...
} type-name
The ShortName of the ImplementationDataType becomes type-name.
The ShortName of the ImplementationDataTypeElement becomes member-name.
The ImplementationDataTypeElement specifies member-type-specifier, which in turn
can be of Category TYPE_REFERENCE, VALUE, STRUCTURE or ARRAY.
Configuration
137
RTA-RTE V6.2.0
Reference Manual
4.5.10
ImplementationDataTypeElement
This is used inside an ImplementationDataTypeElement when specifying a complex
data type (See 4.5.8 ImplementationDataType — Category ARRAY and 4.5.9 ImplementationDataType — Category STRUCTURE). The ImplementationDataTypeElement itself
does not define a C type but is a type specifier either for an array element type or a
structure member type.
ImplementationDataTypeElements are specified in nearly the same way as an
ImplementationDataType. To configure an ImplementationDataTypeElement, refer
to the section for the ImplementationDataType of the category you are interested in,
but use the XML tag IMPLEMENTATION-DATA-TYPE-ELEMENT.
It is recommended that ImplementationDataTypeElements should be of category
TYPE_REFERENCE, though STRUCTURE, ARRAY, and VALUE are supported too. When using
VALUE there is a special caution that you cannot then reference a SwBaseType without
nativeDeclaration. (See 4.5.7 ImplementationDataType — Category VALUE.)
4.5.11
CompuMethod — Category IDENTICAL
A CompuMethod of category IDENTICAL represents the linear data conversion y = 0 +
1x/1. Because it is linear it can be used in data conversion paths that also include
LINEAR CompuMethods. On its own it does not result in any conversion code.
<COMPU-METHOD>
short_name
<CATEGORY>IDENTICAL</CATEGORY>
<UNIT-REF DEST=’UNIT’>ref</UNIT-REF>
</COMPU-METHOD>
The UnitRef is optional.
4.5.12
CompuMethod — Category LINEAR
A CompuMethod of category LINEAR describes a linear data conversion y = num0 +
num1 ∗ x/denom.
<COMPU-METHOD>
short_name
<CATEGORY>LINEAR</CATEGORY>
<UNIT-REF DEST=’UNIT’>ref</UNIT-REF>
( <COMPU-INTERNAL-TO-PHYS> | <COMPU-PHYS-TO-INTERNAL> )
<COMPU-SCALES>
<COMPU-SCALE>
<COMPU-RATIONAL-COEFFS>
<COMPU-NUMERATOR>
<V>int</V>
<V>int</V>
</COMPU-NUMERATOR>
<COMPU-DENOMINATOR>
<V>int</V>
</COMPU-DENOMINATOR>
138
Configuration
RTA-RTE V6.2.0
Reference Manual
</COMPU-RATIONAL-COEFFS>
</COMPU-SCALE>
</COMPU-SCALES>
( </COMPU-INTERNAL-TO-PHYS> | </COMPU-PHYS-TO-INTERNAL> )
</COMPU-METHOD>
The ShortName is used as a reference target.
The UnitRef is optional.
CompuInternalToPhys is used if x is the numerical value and y is the physical value.
CompuPhysToInternal is used if x is the physical value and y is the internal value.
It is permitted to specify both CompuInternalToPhys and CompuPhysToInternal. Each
must be the inverse of the other. It is not necessary to specify both, as RTA-RTE can
derive the inverse of a LINEAR CompuMethod as needed.
There must be exactly two V elements under COMPU-NUMERATOR. The first V element
expresses num0 and the second V element expresses num1.
There must be exactly one V element under COMPU-DENOMINATOR. It expresses denom.
4.5.13
CompuMethod — Category RAT_FUNC
A CompuMethod of category RAT_FUNC is not supported by AUTOSAR R4.0. However
if you configure a data path having the same or exactly similar CompuMethod at each
end then RTA-RTE assumes that the CompuMethods cancel out and treats them as if
they compose to the IDENTICAL transformation.
In cases where unsupported CompuMethod categories do not trivially match, RTA-RTE
rejects the configuration.
4.5.14
CompuMethod — Category TEXTTABLE
A CompuMethod of category TEXTTABLE models a C enumerated type. It is not referenced by an ApplicationPrimitiveDataType like other CompuMethods but by an
ImplementationDataType.
<COMPU-METHOD>
short_name
<CATEGORY>TEXTTABLE</CATEGORY>
<COMPU-INTERNAL-TO-PHYS>
<COMPU-SCALES>
(
<COMPU-SCALE>
<LOWER-LIMIT>int</LOWER-LIMIT>
<UPPER-LIMIT>int</UPPER-LIMIT>
<COMPU-CONST>
<VT>identifier</VT>
</COMPU-CONST>
</COMPU-SCALE>
Configuration
139
RTA-RTE V6.2.0
Reference Manual
...)
</COMPU-SCALES>
</COMPU-INTERNAL-TO-PHYS>
</COMPU-METHOD>
The CompuMethod may contain as many CompuScales as needed. For each CompuScale RTA-RTE generates code similar to the following:
#define symbol
( ( type ) literal-constant )
LowerLimit and UpperLimit must be the same value, i.e. the CompuScale must express
a point range. This value becomes literal-constant.
CompuConst must contain exactly one VT element. The contents of the VT element
become symbol.
The type in the example is derived from the ImplementationDataType that references
the CompuMethod.
4.5.15
DataTypeMappingSet
A DataTypeMappingSet maps ApplicationDataTypes used in a SWCT to
ImplementationDataTypes with which those physical quantities should be represented in the generated code. It is referenced by a Software Component Type so it
is possible that different SWCTs implement the same ApplicationDataType using
different ImplementationDataTypes.
<DATA-TYPE-MAPPING-SET>
short_name
<DATA-TYPE-MAPS>
(
<DATA-TYPE-MAP>
<APPLICATION-DATA-TYPE-REF DEST=’APPLICATION-PRIMITIVE-DATA-TYPE’>
ref</APPLICATION-DATA-TYPE-REF>
<IMPLEMENTATION-DATA-TYPE-REF DEST=’IMPLEMENTATION-DATA-TYPE’>ref</
IMPLEMENTATION-DATA-TYPE-REF>
</DATA-TYPE-MAP>
... )
</DATA-TYPE-MAPS>
</DATA-TYPE-MAPPING-SET>
The DataTypeMappingSet can contain as many DataTypeMap elements as needed and
indeed may contain mappings for ApplicationDataTypes not used by the referencing SWCT(s), allowing sharing of DataTypeMappingSets between SWCTs and between
projects; a DataTypeMap is only considered if the ApplicationDataType is used directly
in the model by a SWCT that references the DataTypeMappingSet.
The ApplicationDataTypeRef and ImplementationDataTypeRef reference the two
types to be mapped together.
The ImplementationDataType must be compatible with the ApplicationDataType.
In particular, for primitive types the
ImplementationDataType must have sufficient range to represent the range of
140
Configuration
RTA-RTE V6.2.0
Reference Manual
the ApplicationDataType, if specified, i.e. if it has DataConstrs. For structures, the ImplementationDataType must have the same number of members
as the ApplicationDataType and the pairs of member types at each position
(the member names need not be the same) must be compatible.
For arrays
the ImplementationDataType must have the same number of elements as the
ApplicationDataType and the element types must be compatible.
4.5.16
TextTableMapping
A TextTableMapping causes RTA-RTE to generate data conversion code to transform
discrete values between a Sender and Receiver or a Client and a Server.
<TEXT-TABLE-MAPPINGS>
<TEXT-TABLE-MAPPING>
<MAPPING-DIRECTION>BIDIRECTIONAL</MAPPING-DIRECTION>
<VALUE-PAIRS>
(
<TEXT-TABLE-VALUE-PAIR>
<FIRST-VALUE>int</FIRST-VALUE>
<SECOND-VALUE>int</SECOND-VALUE>
</TEXT-TABLE-VALUE-PAIR>
... )
</VALUE-PAIRS>
</TEXT-TABLE-MAPPING>
</TEXT-TABLE-MAPPINGS>
TextTableMappings appear within a DataPrototypeMapping. The DataPrototypeMapping contains the context of “First” and “Second” Data Prototype.
MappingDirection indicates whether the mapping is valid when data moves from First
to Second Data Prototype or from Second To First Data Prototype, or whether it will work
in both directions.
If the mapping of value pairs is 1:1 (i.e. no two FirstValue elements are alike and no
two SecondValue elements are alike) then MappingDirection of BIDIRECTIONAL is recommended.
If the mapping is n : 1 (i.e. some two FirstValue elements are alike, then MappingDirection must be FIRST-TO-SECOND.
If the mapping is 1 : n (i.e. some two SecondValue elements are alike, then MappingDirection must be SECOND-TO-FIRST.
If the mapping is n : m then it cannot be used by RTA-RTE and must be split into more
than one mapping. RTA-RTE does not reject the configuration but the generated code
will resolve the ambiguities of the n : m mapping in an unspecified way.
4.5.17
Unit
Unit represents a Unit of measurement of some physical quantity. Data conversion
is possible between data values typed by ApplicationDataTypes having linear Com-
Configuration
141
RTA-RTE V6.2.0
Reference Manual
puMethods (includes IDENTICAL) and having matching or compatible Units. Units are
compatible if they reference the same or exactly similar PhysicalDimension elements.
<UNIT>
short_name
<FACTOR-SI-TO-UNIT>float</FACTOR-SI-TO-UNIT>
<OFFSET-SI-TO-UNIT>float</OFFSET-SI-TO-UNIT>
<PHYSICAL-DIMENSION-REF DEST=’PHYSICAL-DIMENSION’>ref</PHYSICALDIMENSION-REF>
</UNIT>
ShortName is used as a reference target.
FactorSiToUnit is a floating-point decimal number expressing the number of units per SI
unit.
OffsetSiToUnit is a floating-point decimal number expressing the offset to be added to
convert from SI units to the specified unit.
4.5.18
Expression of Constant Values
Constant values are needed in the input model for the initial values of DataPrototypes
and the reserved values of DataTypes used as the “invalid values” for DataPrototypes
with invalidation enabled. These are modelled with ValueSpecifications, either directly
where needed or within reusable ConstantSpecifications that can be referenced where
needed.
4.5.19
NumericalValueSpecification
A NumericalValueSpecification provides a numeric constant value for direct use in the
generated C. No data conversion is performed, even when the DataPrototype is typed
by an ApplicationDataType; the value supplied is assumed to already be in the correct
numerical representation for the mapped ImplementationDataType.
numerical_value_specification ::=
<NUMERICAL-VALUE-SPECIFICATION>
<VALUE>int</VALUE>
</NUMERICAL-VALUE-SPECIFICATION>
4.5.20
ApplicationValueSpecification
An ApplicationValueSpecification provides a physical constant value in a given unit for
a DataPrototype typed by an ApplicationPrimitiveDataType. Static (generation-time)
data conversion is performed to obtain the corresponding numerical representation of
the value, encoded for the mapped ImplementationDataType.
application_value_specification ::=
<APPLICATION-VALUE-SPECIFICATION>
<CATEGORY>VALUE</CATEGORY>
<SW-VALUE-CONT>
<UNIT-REF DEST=’UNIT’>ref</UNIT-REF>
<SW-VALUES-PHYS>
142
Configuration
RTA-RTE V6.2.0
Reference Manual
<V>int</V>
</SW-VALUES-PHYS>
</SW-VALUE-CONT>
</APPLICATION-VALUE-SPECIFICATION>
The referenced unit need not be the same as the unit for the ApplicationPrimitiveDataType of the DataPrototype since data conversion occurs as necessary. Of course
the units need to reference the same physical dimension so that data conversion is
possible.
4.5.21
RecordValueSpecification
A RecordValueSpecification provides a container for the constant values for
each element of a structure, whether of ApplicationRecordDataType or of
ImplementationDataType with category STRUCTURE. The value for each element is
specified by an aggregated ValueSpecification of a class suitable for the data type of
the corresponding element. The values are associated with the structure elements in
declaration order.
record_value_specification ::=
<RECORD-VALUE-SPECIFICATION>
<FIELDS>
(
value_specification
...)
</FIELDS>
</RECORD-VALUE-SPECIFICATION>
4.5.22
ArrayValueSpecification
An ArrayValueSpecification provides a container for the constant values for each element of an array, whether or ApplicationArrayDataType or of ImplementationDataType
with category ARRAY. The value for each element is specified by an aggregated ValueSpecification of a class suitable for the array element data type.
array_value_specification ::=
<ARRAY-VALUE-SPECIFICATION>
<ELEMENTS>
(
value_specification
...)
</ELEMENTS>
</ARRAY-VALUE-SPECIFICATION>
For an array of elements of ApplicationPrimitiveDataType it is permitted to use a mix of
NumericalValueSpecifications and ApplicationValueSpecifications.
4.5.23
ConstantSpecification
A ConstantSpecification provides a free-standing constant that can be referenced from
anywhere that a ValueSpecification can be used.
Configuration
143
RTA-RTE V6.2.0
Reference Manual
constant_specification ::=
<CONSTANT-SPECIFICATION>
short_name
<VALUE-SPEC>
value_specification
</VALUE-SPEC>
</CONSTANT-SPECIFICATION>
4.5.24
ConstantReference
A ConstantReference can be used in place of a ValueSpecification to take the value
from a free-standing ConstantSpecification.
constant_reference ::=
<CONSTANT-REFERENCE>
<CONSTANT-REF DEST=’CONSTANT-SPECIFICATION’>ref</CONSTANT-REF>
</CONSTANT-REFERENCE>
4.5.25
IncludedDataTypeSet
IncludedDataTypeSets can be used to add prefixes to the names of enumerated values in the generated C code (for example see 4.5.14).
included_data_type_set ::=
<INCLUDED-DATA-TYPE-SET>
<DATA-TYPE-REFS>
data_type_ref+
</DATA-TYPE-REFS>
<LITERAL-PREFIX>prefix</LITERAL-PREFIX>
</INCLUDED-DATA-TYPE-SET>
There may be one or more data_type_ref items each of which is a <DATA-TYPE-REF>
element referencing an ImplementationDataType or an ApplicationDataType. The
prefix prefix is added to the names of enumerated values generated from the referenced types.
When an IncludedDataTypeSet references an ApplicationDataType, RTARTE adds prefixes to enumerated value names generated from the
ApplicationDataType and from any mapped ImplementationDataType.
If an ImplementationDataType or an ApplicationDataType is referenced by multiple
IncludedDataTypeSets then each enumeration value name will be generated once for
each IncludedDataTypeSet prefix.
If an ImplementationDataType or ImplementationDataTypeElement of
Category TYPE_REFERENCE references a CompuMethod that results in enumerated value generation and the target of the TYPE_REFERENCE references
a CompuMethod that also results in enumerated value generation then RTARTE will use the CompuMethod in the TYPE_REFERENCE rather than the target.
144
Configuration
RTA-RTE V6.2.0
Reference Manual
4.6
Interfaces
An interface element defines the data elements (sender-receiver), calibration elements
or operations (client-server) that apply to the interface. A sender-receiver interface
is declared using the <SENDER-RECEIVER-INTERFACE> element, a calibration interface using the <CALPRM-INTERFACE> and a client-server interface defined using the
<CLIENT-SERVER-INTERFACE> element.
4.6.1
Sender-Receiver
A sender-receiver interface is defined using the <SENDER-RECEIVER-INTERFACE> element. The element must be named to enable it to be referenced from other elements,
such as port prototypes.
sender_receiver_interface ::=
<SENDER-RECEIVER-INTERFACE>
short_name
( data_element_prototypes )
( mode_groups )
</SENDER-RECEIVER-INTERFACE>
Data Elements
A sender-receiver interface element encapsulates zero or more data element definitions each defined using the <DATA-ELEMENT-PROTOTYPE> element.
data_element_prototypes ::=
<DATA-ELEMENTS>
+data_element
</DATA-ELEMENTS>
data_element ::=
<VARIABLE-DATA-PROTOTYPE>
short_name
( sw_data_def_props_for_measurement )
<TYPE-TREF>ref</TYPE-TREF>
</VARIABLE-DATA-PROTOTYPE >
Each data element references a data type. The reference must refer to an AUTOSAR
data type declared within the AUTOSAR XML configuration.
Mode Declarations
In addition to the (optional) data element prototypes, a sender-receiver interface can
define zero or more mode declaration group prototypes within a <MODE-GROUPS> element.
mode_groups ::=
<MODE-GROUPS>
+mode_declaration_group_prototype
</MODE-GROUPS>
mode_declaration_group_prototype ::=
Configuration
145
RTA-RTE V6.2.0
Reference Manual
<MODE-DECLARATION-GROUP-PROTOTYPE>
short_name
<TYPE-TREF>ref</TYPE-TREF>
</MODE-DECLARATION-GROUP-PROTOTYPE>
Each Mode Declaration Group Prototype element references a mode declaration group
type. The reference must refer to an AUTOSAR <MODE-DECLARATION-GROUP> declared
within the AUTOSAR XML configuration.
4.6.2
Nv-Data
A Nv-Data interface is defined using the <NV-DATA-INTERFACE> element. The element
must be named to enable it to be referenced from other elements, such as port prototypes.
nv_data_interface ::=
<NV-DATA-INTERFACE>
short_name
( nv_data_prototypes )
</NV-DATA-INTERFACE>
Nv-Data Elements
A Nv-Data interface element encapsulates zero or more Nv-data element definitions
each defined using the <VARIABLE-DATA-PROTOTYPE> element.
nv_data_prototypes ::=
<NV-DATAS>
+variable_data_prototype
</NV-DATAS>
Each variable data prototype references a data type. The reference must refer to an
AUTOSAR data type declared within the AUTOSAR XML configuration.
4.6.3
Calibration
A calibration interface is defined using the <CALPRM-INTERFACE> element. The element
must be named to enable it to be referenced from other elements, such as port prototypes.
calprm_interface ::=
<CALPRM-INTERFACE>
short_name
( calibration_element_prototypes )
</CALPRM-INTERFACE>
Calibration Elements
A calibration interface element encapsulates zero or more calibration element prototypes each defined using the <DATA-ELEMENT-PROTOTYPE> element.
calibration_element_prototypes ::=
<CALPRM-ELEMENTS>
146
Configuration
RTA-RTE V6.2.0
Reference Manual
+calprm_element
</CALPRM-ELEMENTS>
calprm_element ::=
<CALPRM-ELEMENT-PROTOTYPE>
short_name
( sw_addr_method_ref )
<TYPE-TREF>ref</TYPE-TREF>
</CALPRM-ELEMENT-PROTOTYPE >
Each calibration element prototype references a data type. The reference must refer
to an AUTOSAR data type declared within the AUTOSAR XML configuration.
A calibration element prototype contains an optional reference to a <SW-ADDR-METHOD>
element:
sw_addr_method_ref ::=
<SW-DATA-DEF-PROPS>
<SW-ADDR-METHOD-REF>ref</SW-ADDR-METHOD-REF>
</SW-DATA-DEF-PROPS>
The <SW-ADDR-METHOD-REF> element must refer to an AUTOSAR <SW-ADDR-METHOD>
element. RTA-RTE packs all elements within an interface that reference the same
<SW-ADDR-METHOD> element into a structure to minimise the size of the required datastructures and to ensure that related elements are allocated to the same region of
memory.
Calibration Data
RTA-RTE can allocate initial values for Calibration data. RTA-RTE creates a data structure
for each calibration element group and when initial values are specified for all members
of a group declares a suitable static initializer containing the values within Rte.c.
See Section 10.5 for details on labels and datastructures created by RTA-RTE.
4.6.4
Client-Server
A client-server interface follows a similar form to a sender-receiver interface with the
exception that the data element definitions are replaced by operation definitions.
The client-server interface element must be named to enable it to be referenced from
other elements, such as port prototypes.
client_server_interface ::=
<CLIENT-SERVER-INTERFACE>
short_name
operation_prototypes
( application_errors )
</CLIENT-SERVER-INTERFACE>
operation_prototypes ::=
<OPERATIONS>
Configuration
147
RTA-RTE V6.2.0
Reference Manual
+operation
</OPERATIONS>
Operation Prototypes
Each operation within the client-server interface element is defined using the
<OPERATION-PROTOTYPE> element that defines the operation name as well as encapsulating the definitions of the formal argument list.
operation ::=
<OPERATION-PROTOTYPE>
short_name
<ARGUMENTS>
+argument
</ARGUMENTS>
( error_references )
</OPERATION-PROTOTYPE>
An operation prototype must define one or more formal parameters using the
<ARGUMENT-PROTOTYPE> element.
argument ::=
<ARGUMENT-PROTOTYPE>
short_name
( sw_data_def_props_for_measurement )
<TYPE-REF>ref</TYPE-REF>
direction
</ARGUMENT-PROTOTYPE>
The specification within an argument prototype of sw_data_def_props is optional. If
present it describes whether the argument is measureable. For more details see Section 4.7.
The short name of the <ARGUMENT-PROTOTYPE> defines the name of the formal parameter.
The type of the parameter is defined by the type reference and must refer to a type
defined in the XML input. Each parameter also has a direction that specifies whether
the parameter is an “in”, “in/out” or “out” parameter.
direction ::=
<DIRECTION>(IN | INOUT | OUT)</DIRECTION>
An operation can be marked as ‘pure’ in which case invocation of the server runnable
entity are not queued but are instead invoked by a direction function call from the client
SWC. This is achievied by marking the runnable entity that implements the server as
“CanBeInvokedConcurrently”, see Section 4.10.9.
A client-server interface can, optionally, define one or more application errors that can
be returned (using the standard C return mechanism) from a runnable entity implementing the server.
148
Configuration
RTA-RTE V6.2.0
Reference Manual
application_errors ::=
<POSSIBLE-ERRORS>
+application_error
</POSSIBLE-ERRORS>
application_error ::=
<APPLICATION-ERROR>
short_name
<ERROR-CODE>int</ERROR-CODE>
</APPLICATION-ERROR>
Declared application errors are defined in the software-component’s application header
file using the template:
RTE_E_<interface_name>_<error_name>
Once an application error has been defined it must be referenced from the associated
operation prototype using an <POSSIBLE-ERROR-REF> element:
error_references ::=
<POSSIBLE-ERROR-REFS>
+error_reference
</POSSIBLE-ERROR-REFS>
error_reference ::=
<POSSIBLE-ERROR-REF>ref</POSSIBLE-ERROR-REF>
The data type for application errors is always Std_ReturnType and thus the return
value for a runnable whose operation invoked event references one or more application
errors is also Std_ReturnType.
4.7
Measurement
Measurement permits communication within the RTE to be monitored by an external
tool.
4.7.1
Enabling Measurement
To enable measurement it must be both globally enabled in the RTE module configuration( see Section 4.19.2) and the individual item must be configured as measurable by
specifying a <SW-DATA-DEF-PROPS> element:
sw_data_def_props_for_measurement ::=
<SW-DATA-DEF-PROPS>
<SW-CALIBRATION-ACCESS>READ-ONLY</SW-CALIBRATION-ACCESS>
</SW-DATA-DEF-PROPS>
Measurement can be enabled for data elements (sender-receiver), arguments (clientserver) and inter-runnable variables.
Data element Prototype —A data element within sender-receiver communication is
enabled for measurement by specifying a <SW-DATA-DEF-PROPS> element either
Configuration
149
RTA-RTE V6.2.0
Reference Manual
in the data element prototype within an interface or, for primitive types, within
data type’s definition. If measurement is enabled/disabled in both places then
the definition within the data element prototype takes precedence.
Argument Prototype —An argument within client-server communication is enabled
for measurement by specifying a <SW-DATA-DEF-PROPS> element either in the
argument prototype within an interface or, for primitive types, within data type’s
definition. If measurement is enabled/disabled in both places then the definition
within the argument prototype takes precedence.
Inter-runnable variable —Measurement can be enabled for an inter-runnable variable (see Section 4.10.3) by specifying a <SW-DATA-DEF-PROPS> element either
in the inter-runnable variable declaration within an internal behavior or, for primitive types, within relevant type’s definition. If measurement is enabled/disabled
in both places then the definition within the inter-runnable variable declaration
prototype takes precedence.
4.7.2
RTA-RTE output
RTA-RTE outputs an XML file that describes each measured item’s RTE-created buffer
variable and associated configuration element (e.g. port and data item).
The XML output format is not defined by AUTOSAR and is therefore RTA-RTE
specific.
The XML root element is <MEASURABLE-INFO>.
measurable ::=
<MEASURABLE-INFO>
( measurable_data )
( measurable_arguments )
( measurable_irvs )
</MEASURABLE-INFO>
Data Element Prototype
Measurable data element prototypes are described by the <MEASURABLE-DATUM> element.
measurable_data ::=
<MEASURABLE-DATA>
*measurable_datum
</MEASURABLE-DATA>
measurable_datum ::=
<MEASURABLE-DATUM>
short-name
<INSTANCE-DATUM>instance_ref</INSTANCE-DATUM>
<SYMBOL>
<NAME>string</NAME>
<TYPE>string</TYPE>
</SYMBOL>
</MEASURABLE-DATA>
150
Configuration
RTA-RTE V6.2.0
Reference Manual
The <SYMBOL> element describes the RTE allocated name and data type of the variable
to be measured. The <INSTANCE-DATUM> element references the associated component prototype, port and data element.
Argument Prototype
Measurable argument prototypes are described by the <MEASURABLE-ARG> element.
measurable_arguments ::=
<MEASURABLE-ARGS>
*measurable_arg
</MEASURABLE-ARGS>
measurable_arg ::=
<MEASURABLE-ARG>
short-name
<INSTANCE-ARG>instance_ref</INSTANCE-ARG>
<SYMBOL>
<NAME>string</NAME>
<TYPE>string</TYPE>
</SYMBOL>
</MEASURABLE-ARG>
The <SYMBOL> element describes the RTE allocated name and data type of the variable
to be measured. The <INSTANCE-ARG> element references the associated component
prototype, port and data element.
Inter-runnable variables
Measurable inter-runnable variables are described by the <MEASURABLE-IRV> element.
measurable_arguments ::=
<MEASURABLE-IRVS>
*measurable_irv
</MEASURABLE-IRVS>
measurable_irv ::=
<MEASURABLE-IRV>
short-name
<INSTANCE-IRV>instance_ref</INSTANCE-IRV>
<SYMBOL>
<NAME>string</NAME>
<TYPE>string</TYPE>
</SYMBOL>
</MEASURABLE-IRV>
The <SYMBOL> element describes the RTE allocated name and data type of the variable
to be measured. The <INSTANCE-ARG> element references the associated component
prototype and variable.
Example
The following XML describes a measured data element, argument and inter-runnable
variable.
Configuration
151
RTA-RTE V6.2.0
Reference Manual
<?xml version="1.0" encoding="UTF-8"?>
<MEASURABLE-INFO xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:
noNamespaceSchemaLocation="measurement.xsd">
<MEASURABLE-DATA>
<MEASURABLE-DATUM>
<SHORT-NAME>SWCI0_pa_value</SHORT-NAME>
<INSTANCE-DATUM>
<SOFTWARE-COMPOSITION-REF>/TMeasurement/Compo</SOFTWARE-COMPOSITION
-REF>
<TARGET-COMPONENT-PROTOTYPE-REF>/TMeasurement/Compo/producer</
TARGET-COMPONENT-PROTOTYPE-REF>
<PORT-PROTOTYPE-REF>/TMeasurement/swc_tx/pa</PORT-PROTOTYPE-REF>
<DATA-ELEMENT-PROTOTYPE-REF>/TMeasurement/if1/value</DATA-ELEMENTPROTOTYPE-REF>
</INSTANCE-DATUM>
<SYMBOL>
<NAME>Rte_RxBuf_0</NAME>
<TYPE>VAR(SInt16, RTE_DATA)</TYPE>
</SYMBOL>
</MEASURABLE-DATUM>
</MEASURABLE-DATA>
<MEASURABLE-ARGS>
<MEASURABLE-ARG>
<SHORT-NAME>SWCI0_sc1_a</SHORT-NAME>
<INSTANCE-ARG>
<SOFTWARE-COMPOSITION-REF>/TMeasurement/Compo</SOFTWARE-COMPOSITION
-REF>
<TARGET-COMPONENT-PROTOTYPE-REF>/TMeasurement/Compo/client</TARGETCOMPONENT-PROTOTYPE-REF>
<PORT-PROTOTYPE-REF>/TClientServer/swc_cli/sc1</PORT-PROTOTYPE-REF>
<ARGUMENT-REF>/TClientServer/ifs/operation/a</ARGUMENT-REF>
</INSTANCE-ARG>
<SYMBOL>
<NAME>Rte_MsBuf_0</NAME>
<TYPE>VAR(SInt16, RTE_DATA)</TYPE>
</SYMBOL>
</MEASURABLE-ARG>
</MEASURABLE-ARGS>
<MEASURABLE-IRVS>
<MEASURABLE-IRV>
<SHORT-NAME>SWCI0_irvex1</SHORT-NAME>
<INSTANCE-IRV>
<SOFTWARE-COMPOSITION-REF>/TMeasurement/Compo</SOFTWARE-COMPOSITION
-REF>
<TARGET-COMPONENT-PROTOTYPE-REF>/TMeasurement/Compo/consumer</
TARGET-COMPONENT-PROTOTYPE-REF>
<VARIABLE-REF DEST="INTER-RUNNABLE-VARIABLE">/
TInterRunnableVariables/IBswc_ex/irvex1</VARIABLE-REF>
</INSTANCE-IRV>
<SYMBOL>
<NAME>Rte_Var_SWCI0_irvex1</NAME>
<TYPE>VAR(SInt32, RTE_DATA)</TYPE>
152
Configuration
RTA-RTE V6.2.0
Reference Manual
</SYMBOL>
</MEASURABLE-IRV>
</MEASURABLE-IRVS>
</MEASURABLE-INFO>
RTA-RTE includes an XML schema describing the XML file created by RTA-RTE, see
{install-fldr}\Auxiliary.
4.8
NVRAM
AUTOSAR R4.0 introduced NvBlockSwComponentTypes for the configuration of RAMbased mirrors of non-volatile data managed by the NVRAM manager (see Section 4.4.2).
RTA-RTE supports two forms of access to the ram-blocks declared within
NvBlockSwComponentTypes; from application SWCs using NvBlockDataMappings and
from the NVRAM manager using ClientServerPorts.
4.8.1
Nv-Block Data Mappings
<NV-BLOCK-DATA-MAPPING> elements configure read and/or write access to ram-blocks
(or to sub-elements of ram-blocks) declared by NvBlockDescriptor elements through
ports categorized by <NV-DATA-INTERFACE>s.
nvblock_data_mappings ::=
<NV-BLOCK-DATA-MAPPINGS>
+ nvblock_data_mapping
</NV-BLOCK-DATA-MAPPINGS>
nvblock_data_mapping ::=
<NV-BLOCK-DATA-MAPPING>
nvram_element
( written_var )
( read_var )
</NV-BLOCK-DATA-MAPPING>
A single <NV-BLOCK-DATA-MAPPING> can declare both read and write access to the
same nvram_element.
NVRAM Element
The nvram_element references the ram-block within the NvBlockDescriptor
via
a
<LOCAL-VARIABLE-REF>,
<AUTOSAR-VARIABLE-IN-IMPL-DATATYPE>
or
<AUTOSAR-VARIABLE-IREF> element.
nvram_element ::=
<NV-RAM-BLOCK-ELEMENT>
( local_variable_ref |
autosar_variable_ref |
autosar_variable_iref )
</NV-RAM-BLOCK-ELEMENT>
local_variable_ref ::=
<LOCAL-VARIABLE-REF>
Configuration
153
RTA-RTE V6.2.0
Reference Manual
ref
</LOCAL-VARIABLE-REF>
autosar_variable_ref ::=
<AUTOSAR-VARIABLE-IN-IMPL-DATATYPE>
<ROOT-VARIABLE-DATA-PROTOTYPE-REF>
ref
</ROOT-VARIABLE-DATA-PROTOTYPE-REF>
( impl_sub_element_mapping )
</AUTOSAR-VARIABLE-IN-IMPL-DATATYPE>
autosar_variable_iref ::=
<AUTOSAR-VARIABLE-IREF>
<ROOT-VARIABLE-DATA-PROTOTYPE-REF>
ref
</ROOT-VARIABLE-DATA-PROTOTYPE-REF>
( appl_sub_element_mapping )
</AUTOSAR-VARIABLE-IREF>
The impl_sub_element_mapping (or appl_sub_element_mapping as appropriate) is
optional; if present it defines a mapping from the port’s Nv-data element to a subelement of the ram-block’s data type.
impl_sub_element_mapping ::=
( <CONTEXT-DATA-PROTOTYPE-REFS>
+ context_ref
</CONTEXT-DATA-PROTOTYPE-REFS> )
<TARGET-DATA-PROTOTYPE-REF>
ref
</TARGET-DATA-PROTOTYPE-REF>
appl_sub_element_mapping ::=
( + context_ref )
<TARGET-DATA-PROTOTYPE-REF>
ref
</TARGET-DATA-PROTOTYPE-REF>
context_ref ::=
<CONTEXT-DATA-PROTOTYPE-REF>
ref
</CONTEXT-DATA-PROTOTYPE-REF>
If present the impl_sub_element_mapping (or appl_sub_element_mapping) defines
zero or more context references and one target reference. Each reference defines one
data type element and, when combined, identify the mapped sub-element of the ramblock.
This release of RTA-RTE does not support mappings for individual elements
of array types.
154
Configuration
RTA-RTE V6.2.0
Reference Manual
Read Access by SWCs
Read access by an application SWC occurs through a port required by the SWC and
provided by the NvBlockSwComponentType.
An NvBlockDataMapping declares read access to a ram-block through a
<READ-NV-DATA> element (the element is “read” since the ram-block is provided by
the NvBlockSwComponentType). The instance references within the <READ-NV-DATA>
element must reference a provide port ON THE NvBlock SWC.
written_var ::=
<READ-NV-DATA>
<AUTOSAR-VARIABLE-IREF>
iref
</AUTOSAR-VARIABLE-IREF>
</READ-NV-DATA>
The iref must reference a provide port and a variable data prototype within the port’s
interface. The port must be categorized by an NvDataInterface and the type of the
variable data prototype must be compatible with the referenced ram-block type.
A single provider port on an NvBlockSwComponentType can have multiple connected
require ports and thus a ram-block mirror can be read by multiple application SWCs.
RTA-RTE uses interrupt blocking to prevent simultaneous writes corrupting reads.
It is not possible to use multiple mappings to associate more than one ram-block with
the same provide port.
Write Access by SWCs
Write access by an application SWC occurs through a port provided by the SWC and
required by the NvBlockSwComponentType.
An NvBlockDataMapping declares write access to a ram-block through
an <WRITTEN-NV-DATA> element.
The port instance reference within the
<WRITTEN-NV-DATA> element must reference a require port.
read_var ::=
<WRITTEN-NV-DATA>
<AUTOSAR-VARIABLE-IREF>
iref
</AUTOSAR-VARIABLE-IREF>
</WRITTEN-NV-DATA>
The <AUTOSAR-VARIABLE-IREF> element must reference a require port and a variable data prototype within the port’s interface. The port must be categorized by an
NvDataInterface and the type of the variable data prototype must be compatible with
the referenced ram-block type.
A single require port can have multiple providers and thus a ram-block mirror can be
updated by multiple application SWCs.
Configuration
155
RTA-RTE V6.2.0
Reference Manual
RTA-RTE does not support fan-out from a single require port to multiple ramblocks.
To configure a single Write API generated for an application SWC to write to more than
one ram-block within a NvBlockSwComponentType then multiple require ports (and multiple NvBlockDataMapping elements) must be configured and connected to the provide
port.
4.8.2
Access by NVRAM manager
For each NvBlockDescriptor the RTE generator creates two API call-backs for the
NVRAM manager. The Rte_GetMirror and Rte_SetMirror APIs do not require any
specific configuration.
4.8.3
Client-Server Ports
Client-server port specifications within an NvBlockDescriptor (Section 4.4.2) cause
RTA-RTE to create call-back API functions to be invoked by the NVRAM manager.
cs_ports ::=
<CLIENT-SERVER-PORTS>
+ ( client_assignment | server_assignment )
</CLIENT-SERVER-PORTS>
A client_assignment references a require port and a server_assignment references
a provide port.
Client (require) ports
Each client_assignment that references a require port categorized by a client-server
interface declares a call-back API function intended to be invoked by the NVRAM
manager. The name of this function is based on the <ROLE> declared within the
<ROLE-BASED-PORT-ASSIGNMENT> element:
client_assignment ::=
<ROLE-BASED-PORT-ASSIGNMENT>
<PORT-PROTOTYPE-REF DEST="R-PORT-PROTOTYPE">
ref
</PORT-PROTOTYPE-REF>
<ROLE>
string
</ROLE>
</ROLE-BASED-PORT-ASSIGNMENT>
If multiple role_based_assignment share the same declared “role” then their actions
are agregated by RTA-RTE.
RTA-RTE recognizes that standardized NvM roles NvMNotifyJobFinished and
NvMNotifyInitBlock and establishes the call-back parameters according to the AUTOSAR RTE and NvM specifications. For other roles the parameters of the generated
call-back function, if any, are taken from the first operation in the referenced require
156
Configuration
RTA-RTE V6.2.0
Reference Manual
port’s interface.
It is not possible to reference just a single operation in the require port therefore the referenced interface should have a single operation.
For each declared role, RTA-RTE creates a function Rte_<role>_<b>_<d> that includes
the servers referenced via the require ports in role based assignments that use role
<role>. The generated function name includes the component prototype name <b>
and the NvBlockDescriptor name <d>.
If the server invoked through the referenced require port is mapped to a task then RTARTE will generate code that writes the request to the server’s queue and waits for the
result. This will mean that the calling task, i.e. the NVRAM manager’s task, will need
to be declared as accessing the events. It is therefore recommended not to map the
server to a task, i.e. omit the TaskRef, in which case RTA-RTE will use a direct function
call to invoke the server.
Server (provide) ports
An NvBlockSwComponentType can also configure provided Client-Server ports. These
ports are allow the C-based API of the MVRAM manager to be invoked via ports on
application SWCs.
A server_assignment references a provide port categorized by a client-server interface:
server_assignment ::=
<ROLE-BASED-PORT-ASSIGNMENT>
<PORT-PROTOTYPE-REF DEST="P-PORT-PROTOTYPE">
ref
</PORT-PROTOTYPE-REF>
<ROLE>
string
</ROLE>
</ROLE-BASED-PORT-ASSIGNMENT>
For each connected provide port referenced from a server_assignment for which
an OperationInvokedEvent is configured RTA-RTE will generate a call to NVRAM manager’s C API.
The runnable entity referenced from the OperationInvokedEvent must be marked as
concurrently invocable (see Section 4.10.9) and the runnable’s symbol must be the
name of the NvM API to be invoked. The parameters passed to the NvM API are formed
from relevant port-defined arguments and the arguments to the relevant client-server
operation. In addition the OperationInvokedEvent should not be mapped to a task to
ensure direct function invocation of the NvM API from within the generated Rte_Call
function.
Configuration
157
RTA-RTE V6.2.0
Reference Manual
4.9
AUTOSAR Modes
Modes within an AUTOSAR system are declared within a <MODE-DECLARATION-GROUP>
element.
mode_group ::=
<MODE-DECLARATION-GROUP>
short_name
<INITIAL-MODE-REF>ref</INITIAL-MODE-REF>
<MODE-DECLARATIONS>
+mode_declaration
</MODE-DECLARATIONS>
</MODE-DECLARATION-GROUP>
mode_declaration ::=
<MODE-DECLARATION>
short_name
</MODE-DECLARATION>
The <MODE-DECLARATION-GROUP> element includes a reference to the group’s initial
mode. This must be a reference to a mode declared within the group.
RTA-RTE supports up to 32 modes per mode-declaration group.
4.10
Internal Behavior
The internal behavior description of a component defines the runnable entities present
and is separate from the description of the component type.
The <INTERNAL-BEHAVIOR> element defines one or more runnable entities using the
<RUNNABLE-ENTITY> element. Each runnable entity is named and the name is used to
reference the entity from other elements in the XML.
The <INTERNAL-BEHAVIOR> also defines events associated with the runnable entities
using the RTE-EVENTS element. Events can include time-triggers for the runnable entity
in which case the period at which the entity is invoked is specified.
internal_behavior ::=
<INTERNAL-BEHAVIOR>
short_name
swc_type_ref
rte_events
( interrunnable_variables )
( exclusive_areas )
( nvram_mappings )
( per_instance_calprms )
( per_instance_memorys )
( port_api_options )
( runnable_entitys )
( shared_calprms )
( multiple_instances )
</INTERNAL-BEHAVIOR>
158
Configuration
RTA-RTE V6.2.0
Reference Manual
The software component type reference indicates for which software component the
internal behavior is defined. All software-component types use the same form of component reference:
swc_type_ref ::=
<COMPONENT-REF>ref</COMPONENT-REF>
4.10.1
RTE Events
RTE Events indicate the action the RTE should take in response to certain stimuli.
rte_events ::=
<EVENTS>
*timing_event
*data_received_event
*data_receive_error_event
*data_send_completed_event
*asynchronous_server_call_returns_event
*operation_invoked_event
*mode_switch_event
*mode_switched_ack_event
</EVENTS>
It is permitted (though of limited utility) for a software-component to define no RTE
Events. However in this case an empty <EVENTS> element must still be included.
An internal behavior for an NvBlockSwComponentType (see Section 4.4.2)
can declare only OperationInvokedEvents and the associated runnable
triggered when the event occurs. The activated runnable may only configure a <SYMBOL> and a <CAN-BE-INVOKED-CONCURRENTLY> flag – no other
attributes are permitted.
Timing Event
A timing event defines the response to a time stimulus and is used to set the period for
a time-triggered runnable entity.
A <TIMING-EVENT> element includes a reference to a runnable entity to start when the
RTE event occurs.
timing_event ::=
<TIMING-EVENT>
short_name
( mode_dependency_list )
<START-ON-EVENT-REF>ref</START-ON-EVENT-REF>
<PERIOD>time</PERIOD>
</TIMING-EVENT>
The <START-ON-EVENT-REF> reference is an absolute reference to a runnable entity declared within the same internal behavior as the RTE event. Activation of the referenced
runnable entity by RTA-RTE in response to the RTE event can be disabled using one or
more mode dependencies—see Section 4.10.2.
Configuration
159
RTA-RTE V6.2.0
Reference Manual
The period of a TIMING-EVENT element must be expressed in seconds. No trailing text
indicating the units is required or permitted. Fractions of a section can be expressed
using floating point format with a period (“.”) as the decimal separator.
A Timing Event cannot be the target of a wait point.
A timing event can have an optional activation offset specified in the ECU configuration
description. A different offset can be specified for each runnable entity instance (i.e.
a different offset for each timing event in each SWC instance). For details, see the
specification of ActivationOffset in Section 4.19.2.
Data Received Event
A data received event defines the response to reception of data or events on a receiver
port.
A <DATA-RECEIVED-EVENT> element includes an instance reference to the data item
received on the port and, optionally, a reference to a runnable entity to start when the
RTE event occurs.
data_received_event ::=
<DATA-RECEIVED-EVENT>
short_name
( mode_dependency_list )
( <START-ON-EVENT-REF>ref</START-ON-EVENT-REF> )
<DATA-IREF>instance_ref</DATA-IREF>
</DATA-RECEIVED-EVENT>
The <START-ON-EVENT-REF> reference is an absolute reference to a runnable entity declared within the same internal behavior as the RTE event. Activation of the referenced
runnable entity by RTA-RTE in response to the RTE event can be disabled using one or
more mode dependencies—see Section 4.10.2.
The <DATA-IREF> instance reference defines the data element to which this event applies and requires a single context reference (the port prototype) and a target reference
(the data element within the interface that categorizes the port).
Data Receive Error Event
A data receive error event defines the runnable entity to activate when one of the
following situations occurs:
• An invalidated data item is received (whether via a notification from COM or by
intra-ECU communication implemented by RTA-RTE), and invalid reception handling
for this data item is not set to REPLACE (in which case a data received event will
occur instead).
• COM notifies RTA-RTE that a periodic data item has not been received within the
configured time and has therefore timed out.
160
Configuration
RTA-RTE V6.2.0
Reference Manual
A <DATA-RECEIVE-ERROR-EVENT> element includes an instance reference to the data
item received on the port and a reference to a runnable entity to start when the RTE
event occurs.
data_receive_error_event ::=
<DATA-RECEIVE-ERROR-EVENT>
short_name
( mode_dependency_list )
( <START-ON-EVENT-REF>ref</START-ON-EVENT-REF> )
<DATA-IREF>instance_ref</DATA-IREF>
</DATA-RECEIVE-ERROR-EVENT>
The <START-ON-EVENT-REF> reference is an absolute reference to a runnable entity declared within the same internal behavior as the RTE event. Activation of the referenced
runnable entity by RTA-RTE in response to the RTE event can be disabled using one or
more mode dependencies—see Section 4.10.2.
The <DATA-IREF> instance reference defines the data element to which this event applies and requires a single context reference (the port prototype) and a target reference
(the data element within the interface that categorizes the port).
The activated runnable entity must use the Rte_IStatus API to read the error state—
therefore the activated runnable should declare read access to the datum (see Section 4.10.10) to gain access to the status.
A Data Receive Error Event cannot be the target of a wait point.
Data Send Completed Event
A data send completed event defines the action taken when data or events have been
transmitted on a provided sender-receiver port.
A <DATA-SEND-COMPLETED-EVENT> element includes a reference to the data send point
and an optional reference to a runnable entity to start when the RTE event occurs.
data_send_completed_event ::=
<DATA-SEND-COMPLETED-EVENT>
short_name
( mode_dependency_list )
( <START-ON-EVENT-REF>ref</START-ON-EVENT-REF> )
<EVENT-SOURCE-REF>ref</EVENT-SOURCE-REF>
</DATA-SEND-COMPLETED-EVENT>
The <START-ON-EVENT-REF> reference is an absolute reference to a runnable entity declared within the same internal behavior as the RTE event. Activation of the referenced
runnable entity by RTA-RTE in response to the RTE event can be disabled using one or
more mode dependencies—see Section 4.10.2.
The <EVENT-SOURCE-REF> reference is a simple reference that defines the data send
point to which this event applies. The send point must be declared within the same
Configuration
161
RTA-RTE V6.2.0
Reference Manual
internal behavior as the RTE event.
Asynchronous Server Call Returns Event
An asynchronous server call returns event defines how the software component client
port handles the return of an asynchronous server call.
An <ASYNCHRONOUS-SERVER-CALL-RETURNS-EVENT> element includes an optional reference to a runnable entity to start when the RTE event occurs, and a reference to the
<ASYNCHRONOUS-SERVER-CALL-POINT> within the runnable entity referenced.
asynchronous_server_call_returns_event ::=
<ASYNCHRONOUS-SERVER-CALL-RETURNS-EVENT>
short_name
( mode_dependency_list )
( <START-ON-EVENT-REF>ref</START-ON-EVENT-REF> )
<EVENT-SOURCE-REF>ref</EVENT-SOURCE-REF>
</ASYNCHRONOUS-SERVER-CALL-RETURNS-EVENT>
The <START-ON-EVENT-REF> reference is an absolute reference to a runnable entity declared within the same internal behavior as the RTE event. Activation of the referenced
runnable entity by RTA-RTE in response to the RTE event can be disabled using one or
more mode dependencies—see Section 4.10.2.
The <EVENT-SOURCE-REF> reference is a simple reference that defines the server call
point to which this event applies. The call point must be declared within the same
internal behavior as the RTE event.
Operation Invoked Event
An operation invoked event defines what the software component server port does in
response to a server request.
An <OPERATION-INVOKED-EVENT> element includes a reference to the server operation
that triggers the event and the runnable entity that acts as the server.
operation_invoked_event ::=
<OPERATION-INVOKED-EVENT>
short_name
( mode_dependency_list )
<START-ON-EVENT-REF>ref</START-ON-EVENT-REF>
<OPERATION-IREF>instance_ref</OPERATION-IREF>
</OPERATION-INVOKED-EVENT>
The <START-ON-EVENT-REF> reference is an absolute reference to a runnable entity declared within the same internal behavior as the RTE event. Activation of the referenced
runnable entity by RTA-RTE in response to the RTE event can be disabled using one or
more mode dependencies—see Section 4.10.2.
The <OPERATION-IREF> instance reference defines the operation to which this event
applies and requires a single context reference (the port prototype) and a target reference (the operation within the interface that categorizes the port).
162
Configuration
RTA-RTE V6.2.0
Reference Manual
An Operation Invoked Event cannot be the target of a wait point.
Mode Switch Event
A Mode Switch event defines the actions of the software component when a mode
manager switches modes using the Rte_Switch API.
A MODE-SWITCH-EVENT element includes a reference to the runnable entity that is
triggered on either ENTRY to or EXIT from the referenced mode.
mode_switch_event ::=
<MODE-SWITCH-EVENT>
short_name
( mode_dependency_list )
<START-ON-EVENT-REF>ref</START-ON-EVENT-REF>
<ACTIVATION>(ENTRY|EXIT)</ACTIVATION>
<MODE-IREF>instance_ref</MODE-IREF>
</MODE-SWITCH-EVENT>
The <START-ON-EVENT-REF> reference is an absolute reference to a runnable entity declared within the same internal behavior as the RTE event. Activation of the referenced
runnable entity by RTA-RTE in response to the RTE event can be disabled using one or
more mode dependencies—see Section 4.10.2.
The <ACTIVATION> element defines whether a Mode Switch Event applies to ENTRY to a
mode or EXIT from a mode. It is not possible for a single mode switch event to apply to
both entry and exit—if runnable activation is required for both then two Mode Switch
Events should be defined.
The <MODE-IREF> within a <MODE-SWITCH-EVENT> element must contain two context
references (respectively, the port prototype and the mode declaration group prototype within the interface categorizing the port prototype) and one target reference (the
mode within the mode declaration group that types the declaration group prototype).
A Mode Switch Event cannot be the target of a wait point.
Mode Switched Acknowledge Event
A ModeSwitchedAck event defines the actions of the software component when a mode
switch is complete.
A <MODE-SWITCHED-ACK-EVENT> element includes an optional reference to the runnable
entity that is triggered after the mode switch defined by the elements reference to a
<MODE-SWITCH-POINT> has completed.
mode_switched_ack_event ::=
<MODE-SWITCHED-ACK-EVENT>
short_name
( mode_dependency_list )
<START-ON-EVENT-REF>ref</START-ON-EVENT-REF>
Configuration
163
RTA-RTE V6.2.0
Reference Manual
<EVENT-SOURCE-REF>ref</EVENT-SOURCE-REF>
</MODE-SWITCH-EVENT>
The <START-ON-EVENT-REF> reference is an absolute reference to a runnable entity declared within the same internal behavior as the RTE event. Activation of the referenced
runnable entity by RTA-RTE in response to the RTE event can be disabled using one or
more mode dependencies—see Section 4.10.2.
The <EVENT-SOURCE-REF> defines the Mode Switch Point to which the event applies.
A Mode Switched Ack Event occurs for the mode instance, not for a particular
mode. Therefore the same RTE Event will occur after each mode switch
irrespective of the requested mode.
A ModeSwitchedAckEvent that is the target of a wait point’s trigger reference produces
a blocking Rte_Feedback API call. It is not valid for a ModeSwitchedAckEvent element
that is the target of a wait point’s trigger reference to also trigger runnable entity activation.
4.10.2
Mode Dependency
An RTE event can define zero or more mode dependencies to control activation of a
referenced runnable entity by RTA-RTE.
mode_dependency_list ::=
<MODE-DEPENDENCY>
<DEPENDENT-ON-MODE-IREFS>
+mode_dependency
</DEPENDENT-ON-MODE-IREFS>
</MODE-DEPENDENCY>
Each mode dependency disables activation of the runnable entity by RTA-RTE when the
specified mode is active.
mode_dependency ::=
<DEPENDENT-ON-MODE-IREF>
instance_ref
</DEPENDENT-ON-MODE-IREF>
The <DEPENDENT-ON-MODE-IREF> within a mode dependency list must contain two context references (respectively, the port prototype and the mode declaration group prototype within the interface categorizing the port prototype) and one target reference (the
mode within the mode declaration group that types the declaration group prototype).
When a mode dependency disables an event that would have written to a
queue (e.g. data receive when isQueued is true) RTA-RTE suppresses both
the write and the runnable entity activation.
164
Configuration
RTA-RTE V6.2.0
Reference Manual
4.10.3
Inter-Runnable Variables
Inter-runnable variables support communication between runnable entities within the
same instance of an AUTOSAR SW-C. An internal behavior can declare zero or more
inter-runnable variables using the <INTER-RUNNABLE-VARIABLE> tag:
interrunnable_variables ::=
<INTER-RUNNABLE-VARIABLES>
+interrunnable_variable
</INTER-RUNNABLE-VARIABLES>
interrunnable_variable ::=
<INTER-RUNNABLE-VARIABLE>
short_name
( sw_data_def_props_for_measurement )
<TYPE-TREF>ref</TYPE-TREF>
<COMMUNICATION-APPROACH>
(EXPLICIT|IMPLICIT)
</COMMUNICATION-APPROACH>
<INIT-VALUE-REF>ref</INIT-VALUE-REF>
</INTER-RUNNABLE-VARIABLE>
Access to an inter-runnable variable, whether read or write, is atomic. If an atomic
read-modify-write operation is required then an exclusive area must be used instead.
The <INIT-VALUE-REF> reference defines the inter-runnable variable’s initial value.
The reference should identify a constant’s value specification and not to the constant
specification element itself.
The specification within an inter-runnable variable of sw_data_def_props is optional. If
present it describes whether the variable is measurable. For more details see Section 4.7.
4.10.4
Exclusive Areas
An internal behavior can declare zero or more exclusive areas that are used to provide
mutual exclusive access to state shared between runnable entities.
The scope of an exclusive area is restricted to a software-component instance and thus an exclusive area cannot be used to control access to state
shared between software-component instances.
exclusive_areas ::=
<EXCLUSIVE-AREAS>
+exclusive_area
</EXCLUSIVE-AREAS>
exclusive_areas ::=
<EXCLUSIVE-AREA>
short_name
</EXCLUSIVE-AREA>
Configuration
165
RTA-RTE V6.2.0
Reference Manual
An <EXCLUSIVE-AREA> can be declared with an optional hint to the RTE generator as to
how the exclusive area should be implemented. See Section 4.19.2.
4.10.5
NVRAM Mapping
An internal behavior can define zero or more NVRAM mappings.
nvram_mappings ::=
<NVRAM-MAPPINGS>
+nvram_mapping
</NVRAM-MAPPINGS>
Each nvram_mapping defines a single mapping for the behavior.
nvram_mapping ::=
<NVRAM-MAPPING>
short_name
<MIRROR-BLOCK-REF>
ref
</MIRROR-BLOCK-REF>
</NVRAM-MAPPINGS>
The <MIRROR-BLOCK-REF> associates an NVRAM mapping with a per-instance memory.
When a mirror block reference is defined, the RTA-RTE RTE generator uses the RamBlockLocationSymbol from the NvRamAllocation within the ECUC as the name of the
instantiated per-instance memory.
4.10.6
Calibration
An internal behavior element can define zero or more per-instance and shared calibration parameters.
Calibration Element
A calibration element prototype declares a single calibratable parameter.
calprm_element::=
<CALPRM-ELEMENT-PROTOTYPE>
short_name
( sw_addr_method_ref )
type_ref
</CALPRM-ELEMENT-PROTOTYPE>
A calibration element within an internal behavior2 can be either per-instance or shared
depending on where it is declared within the internal behavior.
The sw_addr_method_ref is used to aggregate calibration element prototypes from the
same SWC instance (and of the same type) into calibration element groups.
sw_addr_method_ref ::=
2
In addition to declaring calibration parameters within an internal behavior they can also be declared
within a calibration component type. Parameters declared within a calibration component type can be
used by multiple SWC instances.
166
Configuration
RTA-RTE V6.2.0
Reference Manual
<SW-DATA-DEF-PROPS>
<SW-ADDR-METHOD-REF>ref</SW-ADDR-METHOD-REF>
</SW-DATA-DEF-PROPS>
The <SW-ADDR-METHOD-REF> must refer to a <SW-ADDR-METHOD> element.
Per-instance
The <PER-INSTANCE-CALPRMS> element aggregates all calibration elements that are
assigned unique values for each referencing SWC instance.
per_instance_calprms ::=
<PER-INSTANCE-CALPRMS>
+calprm_element
</PER-INSTANCE-CALPRMS>
Each calprm_element definition defines the name, data type, and optionally the swAddrMethod, of a single calibration parameter. The definition of a calprm_element is described in Section 4.6.3.
Shared
The <SHARED-CALMRMS> element aggregates all calibration elements that have common
values for each referencing SWC instance.
shared_calprms ::=
<SHARED-CALPRMS>
+calprm_element
</SHARED-CALPRMS>
Each calprm_element definition defines the name, data type, and optionally the swAddrMethod, of a single calibration parameter.
Initial Values
Initial value assignment for shared and per-instance calibration parameters are contained within instances of the <LOCAL-PARAMETER-INIT-VALUE-ASSIGNMENT> element:
init_values ::=
<INIT-VALUES>
*init_value_assignment
</INIT-VALUES>
An initial value assignment element contains a pair of references; the first to a constant
containing the initial value and the second the associated calibration prototype:
init_value_assignment ::=
<LOCAL-PARAMETER-INIT-VALUE-ASSIGNMENT>
<INIT-VALUE-REF>ref</INIT-VALUE-REF>
<PARAMETER-REF>ref</PARAMETER-REF>
</LOCAL-PARAMETER-INIT-VALUE-ASSIGNMENT>
Configuration
167
RTA-RTE V6.2.0
Reference Manual
The referenced calibration parameter must be in the same InternalBehavior as the LocalParameterInitValueAssignment. The referenced constant and the calibration parameter must have the same underlying type.
4.10.7
Per-Instance Memories
An internal behavior element can define zero or more per-instance memories (PIM) that
are instantiated by RTA-RTE once for each instance of the software-component.
The per-instance memory sections within an AUTOSAR software-component are declared within the <PER-INSTANCE-MEMORYS> element:
per_instance_memorys ::=
<PER-INSTANCE-MEMORYS>
+pim
</PER-INSTANCE-MEMORYS>
Each per-instance memory definition defines the name and type of a single per-instance
memory.
pim ::=
<PER-INSTANCE-MEMORY>
short_name
<TYPE>string</TYPE>
<TYPE-DEFINITION>string</TYPE-DEFINITION>
</PER-INSTANCE-MEMORY>
RTA-RTE uses the <TYPE> and <TYPE-DEFINITION> elements to form the data type of
the per-instance memory through a type definition:
typedef <TYPE-DEFINITION> <TYPE>;
Where <TYPE-DEFINITION> and <TYPE> are extracted from the input. Therefore the
<TYPE-DEFINITION> must be the required C-type and the <TYPE> the data type name.
The <TYPE-DEFINITION> is used without interpretation by RTA-RTE and is not checked
for syntactic correctness.
The <TYPE> of a per-instance memory is visible as a C typedef to a
software-component. Therefore all defined per-instance memories of a single software-component type must have unique short names and types.
4.10.8
Port options
The <PORT-API-OPTION> element defines port-defined argument values and offers control over whether or not the port-API (indirect-API) is generated for a port.
port_api_options ::=
<PORT-API-OPTIONS>
*port_api_option
</PORT-API-OPTIONS>
168
Configuration
RTA-RTE V6.2.0
Reference Manual
Each port_api_option element defines the indirect_api options and/or the port argument
values:
port_api_option ::=
<PORT-API-OPTION>
( indirect_api )
( port_arg_values )
( enable_take_address )
<PORT-REF>ref</PORT-REF>
</PORT-API-OPTION>
The <PORT-REF> element must reference a port within the SWC type associated with
the encapsulating internal behavior.
Indirect-API (Port-API) Control
Support for the indirect API can be enabled/disabled for individual ports within a SWC
type using the <INDIRECT-API> element.
indirect_api ::=
<INDIRECT-API>(true|false)</INDIRECT-API>
Disabling the indirect-API for a port will reduce the ROM usage for a SWC instance.
The indirect-API is always generated if an SWC is declared as supporting
multiple instances irrespective of the <PORT-API-OPTION> settings.
Enable Take Address
When “enable take address” is specified for a port the API mapping generated within
the application header file will permit the address of an API function to be taken. Without this option the mapping may be implemented as a macro that does not support the
address operator.
enable_take_address ::=
<ENABLE-TAKE-ADDRESS>(true|false)</ENABLE-TAKE-ADDRESS>
Port-Defined Argument Values
Port-defined argument values support the interaction between SWCs and Basic Software Modules by the automatic adaptation of server invocation by RTA-RTE depending
on the port used to invoke the server.
Port-defined arguments can only be applied to provided (server) ports.
Each port_arg_values list defines the valid argument values for the port referenced by
the Port-API options element:
port_argument_list ::=
<PORT-ARG-VALUES>
*value_spec
</PORT-ARG-VALUES>
Configuration
169
RTA-RTE V6.2.0
Reference Manual
One port-defined argument is passed to the operations within the client-server interface that categorizes the referenced port for each “value” defined within the argument
list.
value_spec ::=
<xyz-LITERAL>
short_name
<TYPE-TREF>ref</TYPE-TREF>
<VALUE>string</VALUE>
</xyz-LITERAL>
4.10.9
Runnable Entities
The runnable entities within an AUTOSAR software-component are declared within the
<RUNNABLES> element:
runnable_entitys ::=
<RUNNABLES>
+runnable_entity
</RUNNABLES>
The only mandatory information for a runnable entity is its short name and symbol.
However, if the runnable entity needs to interact with the interfaces in the associated
software component then this must be stated explicitly.
runnable_entity ::=
<RUNNABLE_ENTITY>
short_name
( pure )
( data_read_points )
( data_receive_points
( data_send_points )
( data_write_points )
( runnable_entity_runs_in_exclusive_areas )
( mode_switch_points )
( read_variables )
( minimum_start_interval )
( server_call_points )
symbol
( runnable_entity_can_enter_exclusive_areas )
( wait_points )
( written_variables )
</RUNNABLE_ENTITY>
Concurrent execution
The runnable entity responsible for servicing an Operation Invoked Event for a clientserver operation can be marked as subject to concurrent execution (previous releases
of RTA-RTE referred to such runnable entities as ‘pure’) to enable un-queued execution.
pure ::=
<CAN-BE-INVOKED-CONCURRENTLY>
(true|false)
170
Configuration
RTA-RTE V6.2.0
Reference Manual
</CAN-BE-INVOKED-CONCURRENTLY>
For intra-ECU client-server communication, a runnable entity that is marked as concurrently executable will be directly invoked by RTA-RTE irrespective of whether intratask or inter-task communication is involved provided all clients access the server synchronously.
Concurrent execution affects runnable entities activated as a result of an
OperationInvoked RTE event as well as allowing runnables activated by
multiple RTEEvents to be mapped to preemptable tasks.
Write Accesses
When the runnable is to be used to send data on a software component interface using
implicit RTE API it must define the data write points where the data is written by the
runnable entity. Each data write access point needs to be named and must reference a
data item in a sender-receiver interface.
data_write_points ::=
<DATA-WRITE-ACCESSS>
+data_write_point
</DATA-WRITE-ACCESSS>
data_write_point ::=
<DATA-WRITE-ACCESS>
short_name
<DATA-ELEMENT-IREF>
instance_ref
</DATA-ELEMENT-IREF>
</DATA-WRITE-ACCESS>
A data write point is necessary for RTA-RTE to create the Rte_IWrite and
Rte_IInvalidate API calls.
The <DATA-ELEMENT-IREF> instance reference defines the data element to which this
event applies and requires a single context reference (the port prototype) and a target
reference (the data element within the interface that categorizes the port).
4.10.10 Read Accesses
When the runnable is used to read data on a software component interface using implicit RTE API it must define the data read points where the data is read by the runnable
entity. Each data read access point needs to be named and must reference a data item
in a sender-receiver interface.
data_read_points ::=
<DATA-READ-ACCESSS>
+data_read_point
</DATA-READ-ACCESSS>
data_read_point ::=
<DATA-READ-ACCESS>
Configuration
171
RTA-RTE V6.2.0
Reference Manual
short_name
<DATA-ELEMENT-IREF>
instance_ref
</DATA-ELEMENT-IREF>
</DATA-READ-ACCESS>
A data read point is necessary for RTA-RTE to create the Rte_IRead and Rte_IStatus
API calls.
The <DATA-ELEMENT-IREF> instance reference defines the data element to which this
event applies and requires a single context reference (the port prototype) and a target
reference (the data element within the interface that categorizes the port).
Receive Points
When the runnable is used to receive data on a software component interface using the
explicit RTE API it must define the data receive points where the data is received. Each
data receive point needs to be named and reference a data item in a sender-receiver
interface.
data_receive_points ::=
<DATA-RECEIVE-POINTS>
+data_receive_point
</DATA-RECEIVE-POINTS>
data_receive_point ::=
<DATA-RECEIVE-POINT>
short_name
<DATA-ELEMENT-IREF>
instance_ref
</DATA-ELEMENT-IREF>
</DATA-RECEIVE-POINT>
A data receive point is necessary for RTA-RTE to create the Rte_Receive API calls.
The <DATA-ELEMENT-IREF> instance reference defines the data element to which this
event applies and requires a single context reference (the port prototype) and a target
reference (the data element within the interface that categorizes the port).
Send Points
When the runnable is used to send data on a software component interface using the
explicit RTE API it must define which data items are sent. Each data send point needs
to be named and must reference a data item in a sender-receiver interface.
data_send_points ::=
<DATA-SEND-POINTS>
+data_send_point
</DATA-SEND-POINTS>
data_send_point ::=
<DATA-SEND-POINT>
172
Configuration
RTA-RTE V6.2.0
Reference Manual
short_name
<DATA-ELEMENT-IREF>
instance_ref
</DATA-ELEMENT-IREF>
</DATA-SEND-POINT>
A data send point is necessary for RTA-RTE to create the Rte_Send or Rte_Write API
calls.
The <DATA-ELEMENT-IREF> instance reference defines the data element to which this
event applies and requires a single context reference (the port prototype) and a target
reference (the data element within the interface that categorizes the port).
Mode Switch Points
If a runnable is used as a mode manager that will make an Rte_Switch API call over a
sender-receiver interface, then the runnable needs to define a mode switch point.
A mode switch point is necessary for RTA-RTE to create the Rte_Switch API call.
Each mode switch point needs to be named and must reference a mode declaration
group prototype in a sender-receiver interface.
mode_switch_points ::=
<MODE-SWITCH-POINTS>
+mode_switch_point
</MODE-SWITCH-POINTS>
mode_switch_point ::=
<MODE-SWITCH-POINT>
short_name
<MODE-GROUP-IREF>
<P-PORT-PROTOTYPE-REF>
ref
</P-PORT-PROTOTYPE-REF>
<MODE-DECLARATION-GROUP-PROTOTYPE-REF>
ref
</MODE-DECLARATION-GROUP-PROTOTYPE-REF>
</MODE-GROUP-IREF>
</MODE-SWITCH-POINT>
The <MODE-SWITCH-IREF> instance reference defines the mode declaration group prototype to which the switch point applies. The instance reference requires a port prototype reference and a mode declaration group prototype reference (which must be
within the interface that categorizes the port).
Server Call Points
If a runnable is used as a client that will make a server call over a client-server interface,
then the runnable needs to define the server interface operation(s) that it calls.
server_call_points ::=
Configuration
173
RTA-RTE V6.2.0
Reference Manual
<SERVER-CALL-POINTS>
+ ( asynchronous_server_call_point |
synchronous_server_call_point )
</SERVER-CALL-POINTS>
asynchronous_server_call_point ::=
<ASYNCHRONOUS-SERVER-CALL-POINT>
short_name
<OPERATION-IREFS>
+operation_iref
</OPERATION-IREFS>
</ASYNCHRONOUS-SERVER-CALL-POINT>
synchronous_server_call_point ::=
<SYNCHRONOUS-SERVER-CALL-POINT>
short_name
<OPERATION-IREFS>
+operation_iref
</OPERATION-IREFS>
<TIMEOUT>time</TIMEOUT>
</SYNCHRONOUS-SERVER-CALL-POINT>
The <TIMEOUT> defines the maximum time an inter-ECU call will block before returning.
No trailing text indicating the units is required or permitted. Fractions of a second can
be expressed using floating point format with a period (“.”) as the decimal separator.
operation_iref ::=
<OPERATION-IREF>instance_ref</OPERATION-IREF>
The <OPERATION-IREF> instance reference defines the operation to which this event
applies and requires a single context reference (the port prototype) and a target reference (the operation within the interface that categorizes the port).
RTA-RTE supports at most one operation_iref reference per server call point.
Symbol
The SYMBOL element provides the C name of the function that implements the runnable
entity.
symbol ::=
<SYMBOL>C-Ident</SYMBOL>
RTA-RTE expects that the symbol will be defined in an implementation of a software
component. A protyotype for the runnable entity is declared in the component’s application header file.
Blocking API calls
When a runnable needs to block (i.e. wait on events) it must name the points at which
it waits and, for each point, define the associated <RTE-EVENT>.
174
Configuration
RTA-RTE V6.2.0
Reference Manual
wait_points ::=
<WAIT-POINTS>
+wait_point
</WAIT-POINTS>
wait_point ::=
<WAIT-POINT>
short_name
<TRIGGER-REFS>
+( <TRIGGER-REF>ref</TRIGGER-REF> )
</TRIGGER-REFS>
<TIMEOUT>time</TIMEOUT>
</WAIT-POINT>
The <TIMEOUT> elements defines the maximum time, in seconds, a blocking API call
will wait before returning. No trailing text indicating the units is required or permitted.
Fractions of a second can be expressed using floating point format with a period (“.”)
as the decimal separator.
When a blocking API call is required the <RTE-EVENT> referenced within a
trigger reference must not also reference a runnable entity.
A Wait Point is only permitted to reference the following RTE events:
• Data Received
• Data Send Completed
• Asynchronous Server Call Returns
• Mode Switched Acknowledge
Access to Exclusive Areas
Each runnable can specify whether it can get access to a critical section at runtime,
either implicitly when invoked by the generated RTE, or explicitly by making an appropriate RTE call.
Explicit exclusive areas are defined by a “runnable can enter” element:
runnable_entity_can_enter_exclusive_areas ::=
<CAN-ENTER-EXCLUSIVE-AREA-REFS>
+exclusive_area_reference
</CAN-ENTER-EXCLUSIVE-AREA-REFS>
exclusive_area_reference ::=
<CAN-ENTER-EXCLUSIVE-AREA-REF>
ref
</CAN-ENTER-EXCLUSIVE-AREA-REF>
Implicit exclusive areas are defined within a “runs inside exclusive area” element:
Configuration
175
RTA-RTE V6.2.0
Reference Manual
runnable_entity_runs_in_exclusive_areas ::=
<RUNS-INSIDE-EXCLUSIVE-AREA-REFS>
+implicit_area_reference
</RUNS-INSIDE-EXCLUSIVE-AREA-REFS>
implicit_area_reference ::=
<RUNS-INSIDE-EXCLUSIVE-AREA-REF>
ref
</RUNS-INSIDE-EXCLUSIVE-AREA-REF>
Exclusive areas can only be used for concurrency control within a softwarecomponent instance.
Read Variables
Each runnable can specify whether it can get “read” access to an inter-runnable variable at runtime, either implicitly or explicitly, by making an appropriate RTE call.
read_variables ::=
<READ-VARIABLE-REFS>
+read_variable
</READ-VARIABLE-REFS>
read_variable ::=
<READ-VARIABLE-REF>ref</READ-VARIABLE-REF>
Written Variables
Each runnable can specify whether it can get “write” access to an inter-runnable variable at runtime, either implicitly or explicitly, by making an appropriate RTE call.
written_variables ::=
<WRITTEN-VARIABLE-REFS>
+written_variable
</WRITTEN-VARIABLE-REFS>
written_variable ::=
<WRITTEN-VARIABLE-REF>ref</WRITTEN-VARIABLE-REF>
Minimum Start Interval
The <MINIMUM-START-INTERVAL> element specifies the time (in seconds) between
which any two executions of the runnable are guaranteed to be separated.
minimum_start_interval ::=
<MINIMUM-START-INTERVAL>
time
</MINIMUM-START-INTERVAL>
A minimum start interval specification is typically used with runnable entities triggered
by DataReceivedEvents to limit the rate at which events are processed. However a
minimum start interval can be applied to any runnable entity except for those triggered
by an OperationInvokedEvent.
176
Configuration
RTA-RTE V6.2.0
Reference Manual
4.10.11 Multiple Instantiation
The <SUPPORTS-MULTIPLE-INSTANTIATION> element determines whether or not multiple instances of a software component are permitted.
multiple_instances ::=
<SUPPORTS-MULTIPLE-INSTANTIATION>
( true | false )
</SUPPORTS-MULTIPLE-INSTANTIATION>
A value of “true” indicates that multiple instances of a software-component are permitted whereas “false” indicates that multiple instances are forbidden.
RTA-RTE is able to apply higher levels of optimization, especially at the “Contract” generation stage, when multiple instantiation is forbidden.
4.11
Implementation
The implementation description of a software component defines its implementation
characteristics.
This release of RTA-RTE uses the <SWC-IMPLEMENTATION> element to determine
whether or not a software-component is delivered as source code or object-code.
implementation ::=
<SWC-IMPLEMENTATION>
short_name
( code_descriptor )
<BEHAVIOR-REF>ref</BEHAVIOR-REF>
<SWC-IMPLEMENTATION>
An <IMPLEMENTATION> or <SWC-IMPLEMENTATION> element references an internal behavior element that in turn references a SWC type. This relationship permits multiple
implementation elements to be “associated” with a particular SWC type, e.g. one implementation for each supported processor.
RTE generation occurs for a specific implementation and therefore RTA-RTE
needs additional information in the form of an implementation selection element to determine which <IMPLEMENTATION> or <SWC-IMPLEMENTATION>
element to use for a specific SWC instance. See Section 4.19.2
4.11.1
Code Descriptor
The <CODE-DESCRIPTOR> element determines whether the SWC type for which the implementation is associated is delivered as source-code or object-code.
code_descriptor ::=
<CODE-DESCRIPTORS>
<CODE>
short_name
<ARTIFACT-DESCRIPTORS>
<AUTOSAR-ENGINEERING-OBJECT>
Configuration
177
RTA-RTE V6.2.0
Reference Manual
<CATEGORY>(SWSRC|SWOBJ)</CATEGORY>
</AUTOSAR-ENGINEERING-OBJECT>
</ARTIFACT-DESCRIPTORS>
</CODE>
</CODE-DESCRIPTORS>
When an SWC instance is delivered as “SWSRC”, RTA-RTE will elide the generation of
functions in the generated RTE wherever possible; for example a client-server Rte_Call
with an optimized API mapping that directly invokes the server runnable does not require the body of the RTE Call API to be generated.
4.12
Signals
A signal, or message, is the basic unit of communication between ECUs, usually carrying a single logical item of data, such as a value representing engine temperature.
AUTOSAR distinguishes between three kinds of signal: system signals, interaction layer
signals (i-signals) and COM signals, all of which may refer to the same data item. To understand the configuration of inter-ECU commumication within RTA-RTE, it is important
to understand what is referred to by the different types of signal.
System Signal —the most abstract representation of a message used to carry data,
and is the kind of signal referred to when data mappings are configured.
I-Signal —an instance of a system signal in a particular interaction layer PDU. A separate class is used in order to support “fan-out”, enabling a single system signal
to be referred to in multiple PDU instances, sent to different destinations. Consequently, there may be n i-signals corresponding to a single system signal.
Com signal —an element of the COM module configuration, representing a concrete
instance of a signal. Com signals correspond directly to i-signals, i.e. for every
i-signal in the system definition that is required for the ECU being generated,
there should be a Com signal. The configuration of Com signals includes detailed
information about the communication stack that is not included in the high-level
system definition, such as repetition counts, filters, etc.
The <SYSTEM-SIGNAL> element defines an AUTOSAR signal.
system_signal ::=
<SYSTEM-SIGNAL>
short_name
<LENGTH>int</LENGTH>
</SYSTEM-SIGNAL>
The signal length is defined in bits. All other properties of the signal, such as its bit
position, are set when a signal type is mapped into a frame type.
An I-Signal describes an instance of a system signal in a particular interaction layer
PDU and hence the <I-SIGNAL> references a <SYSTEM-SIGNAL>.
178
Configuration
RTA-RTE V6.2.0
Reference Manual
i_signal ::=
<I-SIGNAL>
short_name
<SYSTEM-SIGNAL-REF>ref</SYSTEM-SIGNAL-REF>
</I-SIGNAL>
An I-Signal is referenced from an <I-SIGNAL-TO-I-PDU-MAPPING> when the signal is
packed into an I-PDU—see Section 4.14.
An I-Signal describes an instance of a system signal in a particular interaction layer
PDU and hence the <I-SIGNAL> references a <SYSTEM-SIGNAL>.
i_signal ::=
<I-SIGNAL>
short_name
<SYSTEM-SIGNAL-REF>ref</SYSTEM-SIGNAL-REF>
</I-SIGNAL>
An I-Signal is referenced from an <I-SIGNAL-TO-I-PDU-MAPPING> when the signal is
packed into an I-PDU—see Section 4.14.
4.13
System Signal Group
The <SYSTEM-SIGNAL-GROUP> element defines a group of AUTOSAR signals that can be
sent and received atomically.
signal_group_type ::=
<SYSTEM-SIGNAL-GROUP>
short_name
<SYSTEM-SIGNALS-REFS>
+signal_ref
</SYSTEM-SIGNALS-REFS>
</SYSTEM-SIGNAL-GROUP>
signal_ref ::=
<SYSTEM-SIGNALS-REF>ref</SYSTEM-SIGNALS-REF>
4.14
PDU Type
The <SIGNAL-I-PDU> element captures the definition of an I-PDU including the position
of all signals within the frame.
pdu_type ::=
<SIGNAL-I-PDU>
short_name
<LENGTH>int</LENGTH>
<SIGNAL-TO-PDU-MAPPINGS>
+signal_to_pdu_mapping
</SIGNAL-TO-PDU-MAPPINGS>
</SIGNAL-I-PDU>
The PDU length is specified in bits.
Configuration
179
RTA-RTE V6.2.0
Reference Manual
Each <I-SIGNAL-TO-I-PDU-MAPPING> element defines the name, packing order and
start position in bits of a referenced I-signal:
signal_to_pdu_mapping ::=
<I-SIGNAL-TO-I-PDU-MAPPING>
short_name
<PACKING-BYTE-ORDER>
( MOST-SIGNIFICANT-BYTE-FIRST |
MOST-SIGNIFICANT-BYTE-LAST )
</PACKING-BYTE-ORDER>
<SIGNAL-REF>ref</SIGNAL-REF>
<START-POSITION>int</START-POSITION>
</I-SIGNAL-TO-I-PDU-MAPPING>
The signal start position within the frame type is specified in bits.
The <SIGNAL-REF> element must refer to a <I-SIGNAL> defined in the input.
4.15
ECU Types
The <ECU> element captures the definition of an ECU type.
ecu ::=
<ECU>
short_name
( ecu_abstraction_ref )
</ECU>
The communication buffer definition is not used by RTA-RTE but must be specified for
the XML to be valid.
4.16
Composition
A composition defines instances of component types and the connections between
ports.
composition_type ::=
<COMPOSITION-TYPE>
short_name
component_prototypes
connector_definitions
port_prototypes
</COMPOSITION-TYPE>
4.16.1
Component Prototypes
A composition creates the component prototypes—in the XML input these are defined
using the <COMPONENTS> element:
component_instances ::=
<COMPONENTS>
+component_prototype
</COMPONENTS>
180
Configuration
RTA-RTE V6.2.0
Reference Manual
Each component prototype defines two pieces of information; a name so the prototype
can be referenced from other XML elements and a reference to the relevant softwarecomponent type.
component_prototype ::=
<COMPONENT-PROTOTYPE>
short_name
<TYPE-TREF>ref</TYPE-TREF>
</COMPONENT-PROTOTYPE>
4.16.2
Connector Definitions
The connector definitions define the connections between provided and required ports.
connector_definitions ::=
<CONNECTORS>
+assembly_connector
+delegation_connector
</CONNECTORS>
Assembly Connector
An assembly connector connects provided and required ports within a composition (and
therefore the connection should not span a composition). A delegation connector “exports” ports within a composition to enable compositions to be further composed into
higher level compositions.
Each assembly connector defines two port instances; a provided and required port.
assembly_connector ::=
<ASSEMBLY-CONNECTOR-PROTOTYPE>
short_name
<PROVIDER-IREF>instance_ref</PROVIDER-IREF>
<REQUESTER-IREF>instance_ref</REQUESTER-IREF>
</ASSEMBLY-CONNECTOR-PROTOTYPE>
The <PROVIDER-IREF> instance reference defines the providing port prototype to which
this connector applies and requires a single context reference (the component prototype) and a target reference (the port prototype within the SWC type).
The <REQUIRER-IREF> instance reference defines the requiring port prototype to which
this connector applies and requires a single context reference (the component prototype) and a target reference (the port prototype within the SWC type).
For both <PROVIDER-IREF> and <REQUIRER-IREF> instance references the referenced
component prototype must be within the same composition as the assembly connector.
Delegation Connector
A delegation connector defines two port prototypes which must either both be provided
or both be required.
delegation_connector ::=
Configuration
181
RTA-RTE V6.2.0
Reference Manual
<DELEGATION-CONNECTOR-PROTOTYPE>
short_name
<INNER-PORT-IREF>instance_ref</INNER-PORT-IREF>
<OUTER-PORT-REF>instance_ref</OUTER-PORT-IREF>
</DELEGATION-CONNECTOR-PROTOTYPE>
The instance reference within the <INNER-PORT-IREF> should refer to a port prototype
on a component prototype within the composition, whereas the reference within the
<OUTER-PORT-REF> should refer to a port prototype of the composition itself.
Delegation connectors must always connect ports of the same type. RTARTE flags attempts to connect PPorts to RPorts using delegation connectors
as invalid configurations.
Service Connector
In addition to assembly and delegation connectors, RTA-RTE supports a third type of
connector, the “SERVICE-CONNECTOR-PROTOTYPE”, which is used to connect a software component to an AUTOSAR service. However, service connectors should not appear in a standard software composition, but are placed instead in the ECU’s software
composition, which is also where services themselves are configured on an ECU (see
Section ??).
4.16.3
Port Prototypes
A delegation connector connects a port prototype on a component prototype within the
composition to a port prototype defined within the composition.
port_prototypes::=
<PORTS>
+port_prototype
</PORTS>
The definition of port prototypes is covered in Section 4.4.1.
The port prototype within the composition can be either the source or destination of
the delegation connector.
4.17
ECU Instances
A system topology type defines the instances of ECU types:
ecu_instances ::=
<ECU-INSTANCES>
+ecu-instance
</ECU-INSTANCES>
Each ECU instance is defined using an <ECU-INSTANCE> element. As with the <SYSTEM>,
the ECU instance is named and therefore can be referenced from other elements:
ecu_instance ::=
<ECU-INSTANCE>
182
Configuration
RTA-RTE V6.2.0
Reference Manual
short_name
<ECU-TREF>ref</ECU-TREF>
( ecu_port_instances )
</ECU-INSTANCE>
ecu_instance ::=
<ECU-INSTANCE>
short_name
( ecu_connectors )
</ECU-INSTANCE>
The <ECU-TREF> element must refer to an ECU element defined within the input.
Before an ECU instance can be referenced, for example on the command
line, a topology instance must be defined that references the encapsulating
system topology type.
The ECU instance defines zero or more communication port instances:
ecu_port_instances ::=
<PORT-INSTANCES>
+ecu_port_instance
</PORT-INSTANCES>
ecu_connectors ::=
<CONNECTORS>
+communication_connector
</CONNECTORS>
communication_connector ::=
<COMMUNICATION-CONNECTOR>
short_name
<ECU-COMM-PORT-INSTANCES/>
</COMMUNICATION-CONNECTOR>
RTA-RTE does not use the <ECU-COMM-PORT-INSTANCE> element.
A communication port instance defines the port speed and the relevant port type
(within the ECU type):
ecu_port_instance ::=
<CAN-COMMUNICATION-PORT-INSTANCE>
short_name
<COMM-PORT-ID>int</COMM-PORT-ID>
<COMMUNICATION-SPEED-PORT>
int
</COMMUNICATION-SPEED-PORT>
<PORT-TREF>ref</PORT-TREF>
<PROTOCOL-VERSION>
( L-2-0-A | L-2-0-B )
</PROTOCOL-VERSION>
</CAN-COMMUNICATION-PORT-INSTANCE>
Configuration
183
RTA-RTE V6.2.0
Reference Manual
The <PORT-TREF> element references an <ECU-COMMUNICATION-PORT> on the ECU type.
It should references a communication port on the same ECU type as specified within
the <ECU-INSTANCE>.
The <PROTOCOL-VERSION> element defines whether the CAN communication port is
CAN 2.0a (L-2-0-A) or CAN 2.0b (L-2-0-B) compliant.
4.18
System Description
The system description defines the core elements of an AUTOSAR system including
how SWC prototypes are mapped onto the available ECU instances and how AUTOSAR
signals are mapped onto Com signals.
A system definition must be named so that other XML elements can refer to the system.
system ::=
<SYSTEM>
short_name
( mapping )
sw_composition
</SYSTEM>
4.18.1
Mapping Sets
The mapping of both component instances to ECU instances and, for inter-ECU communication, data element prototypes to system signals is performed by the mapping
sets:
mapping ::=
<MAPPING>
short_name
( data_mappings )
( swc_mappings )
</MAPPING>
The two mapping sets are responsible for mapping component interface communication to physical data transmission and mapping components to ECUs.
4.18.2
Data Mapping
The Data Mapping maps communication between software-components to physical
(network) data transmission.
There are two categories of data mapping: those for sender-receiver and those for
client-server communication. These may be freely mixed within the <DATA-MAPPINGS>
block:
data_mappings ::=
<DATA-MAPPINGS>
*( sender_receiver_mapping | client_server_mapping )
<DATA-MAPPINGS>
184
Configuration
RTA-RTE V6.2.0
Reference Manual
Sender-Receiver Communication
Sender-receiver mappings map a data element prototype, part of a sender-receiver
interface, either to a single signal (if the data type is primitive), or to a signal group (if
the data type is complex).
sender_receiver_mapping ::=
( sender_receiver_signal_mapping |
sender_receiver_signal_group_mapping )
sender_receiver_signal_mapping ::=
<SENDER-RECEIVER-TO-SIGNAL-MAPPING>
data_element_iref
signal_ref
</SENDER-RECEIVER-TO-SIGNAL-MAPPING>
sender_receiver_signal_group_mapping ::=
<SENDER-RECEIVER-TO-SIGNAL-GROUP-MAPPING>
data_element_iref
signal_group_ref
type_mapping
</SENDER-RECEIVER-TO-SIGNAL-GROUP-MAPPING>
Data element instances consist of references to a software component instance within
a composition, a port, and a data element itself, which appears within the description
of the sender-receiver interface that characterizes the port.
data_element_iref ::=
<DATA-ELEMENT-IREF>
+component_prototype_ref
<PORT-PROTOTYPE-REF>ref<PORT-PROTOTYPE-REF>
<DATA-ELEMENT-REF>ref</DATA-ELEMENT-REF>
</DATA-ELEMENT-IREF>
The <DATA-ELEMENT-IREF> element includes one <COMPONENT-PROTOTYPE-REF> for
each level of the composition hierarchy—when nested compositions are present multiple <COMPONENT-PROTOTYPE-REF> are necessary.
component_prototype_ref ::=
<COMPONENT-PROTOTYPE-REF>
ref
</COMPONENT-PROTOTYPE-REF>
signal_ref ::=
<SIGNAL-REF>ref</SIGNAL-REF>
signal_group_ref ::=
<SIGNAL-GROUP-REF>ref</SIGNAL-GROUP-REF>
Complex types are mapped to signal groups: these types may be either records or
arrays.
Configuration
185
RTA-RTE V6.2.0
Reference Manual
type_mapping ::=
<TYPE-MAPPING>
( sr_record_type_mapping | sr_array_type_mapping )
</TYPE-MAPPING>
Records are mapped using the <SENDER-REC-RECORD-TYPE-MAPPING> element:
sr_record_type_mapping ::=
<SENDER-REC-RECORD-TYPE-MAPPING>
<RECORD-ELEMENT-MAPPINGS>
+sr_record_element_mapping
</RECORD-ELEMENT-MAPPINGS>
</SENDER-REC-RECORD-TYPE-MAPPING>
Each record element, whether a primitive or complex type, is mapped using a
<SENDER-REC-RECORD-ELEMENT-MAPPING> element.
sr_record_element_mapping ::=
<SENDER-REC-RECORD-ELEMENT-MAPPING>
( sr_simple_record_element_mapping | sr_complex_record_element_mapping
)
</SENDER-REC-RECORD-ELEMENT-MAPPING>
Record elements can be primitive or complex types. For an element which is a primitive
type the mapping references a single signal.
sr_simple_record_element_mapping ::=
sr_record_element_iref
signal_ref
For record elements that are themselves complex types a nested mapping element is
used.
sr_complex_record_element_mapping ::=
<COMPLEX-TYPE_MAPPING>
( sr_record_type_mapping | sr_array_type_mapping )
</COMPLEX-TYPE_MAPPING>
sr_record_element_ref
The sr_record_element_ref references the relevant record element.
sr_record_element_ref ::=
<RECORD-ELEMENT-REF>
ref
</RECORD-ELEMENT-REF>
Arrays are mapped element-by-element, in a similar way to records, with each element
being mapped to a separate signal:
sr_array_type_mapping ::=
<SENDER-REC-ARRAY-TYPE-MAPPING>
<ARRAY-ELEMENT-MAPPINGS>
+sr_array_element_mapping
186
Configuration
RTA-RTE V6.2.0
Reference Manual
</ARRAY-ELEMENT-MAPPINGS>
</SENDER-REC-ARRAY-TYPE-MAPPING>
Each element of the array is mapped using a <SENDER-REC-ARRAY-ELEMENT-MAPPING>
element.
sr_array_element_mapping ::=
<SENDER-REC-ARRAY-ELEMENT-MAPPING>
( sr_simple_array_element_mapping | sr_complex_array_element_mapping )
</SENDER-REC-ARRAY-ELEMENT-MAPPING>
Array elements can be primitive or complex types. For an element which is a primitive
type the mapping references a single signal.
sr_simple_array_element_mapping ::=
sr_array_element_ref
signal_ref
For array elements that are themselves complex types a nested mapping element is
used.
sr_complex_array_element_mapping ::=
<COMPLEX-TYPE_MAPPING>
sr_record_type_mapping
</COMPLEX-TYPE_MAPPING>
sr_array_element_ref
Note the restriction here that an array may not contain nested array-type elements—
only records can be nested.
sr_array_element_ref ::=
<INDEXED-ARRAY-ELEMENT>
<ARRAY-ELEMENT-REF>ref</ARRAY-ELEMENT-REF>
<INDEX>int</INDEX>
</INDEXED-ARRAY-ELEMENT>
The <INDEX> gives the position of the mapped element within the array; the
<ARRAY-ELEMENT-REF> refers to the type of the array element, and should therefore
have the same value for all the mapped elements of a given array.
Client-Server Communication
The client-sever to protocol mappings maps client-sever interface communication to
system signals via an embedded reference to a communication protocol
client_server_to_protocol_mappings ::=
<CLIENT-SERVER-TO-PROTOCOL-MAPPING>
<CS-PARAMETER-MAPPINGS>
+ client_server_parameter_mapping
<CS-PARAMETER-MAPPINGS>
<MAPPED-OPERATION-IREF>
instance_ref
Configuration
187
RTA-RTE V6.2.0
Reference Manual
</MAPPED-OPERATION-IREF>
</CLIENT-SERVER-TO-PROTOCOL-MAPPING>
The <MAPPED-OPERATION-IREF> instance reference requires three context references
(the component prototype, the port prototype within the component prototype and
the operation within the interface categorizing the port) and a target reference (the
argument within the operation).
client_server_parameter_mapping ::=
<CLIENT-SERVER-PARAMETER-MAPPING>
<MAPPED-PARAMETER-IREF>
instance_ref
</MAPPED-PARAMETER-IREF>
<USED-COMM-PROTO-SIGNAL-IREF>
instance_ref
</USED-COMM-PROTO-SIGNAL-IREF>
</CLIENT-SERVER-PARAMETER-MAPPING>
The <MAPPED-PARAMETER-IREF> instance reference requires three context references
(the component prototype, the port prototype within the component prototype and
the operation within the interface categorizing the port) and a target reference (the
argument within the operation).
The <USED-COMM-PROTO-SIGNAL-IREF> instance reference merely requires a target reference; no context references are required. The target reference must refer to a
<COMM-PROTOCOL-SIGNAL-ROLE> defined in the input.
Client-Server Communication
The client-sever to signal mappings map client-server interface communication to system signals in a way similar to the mapping of sender-receiver communications. In the
client-server case, a signal group is always used, holding not only the signals for the
parameters of the operation, but also those for various elements of meta-data, such as
sequence counters.
client_server_mapping ::=
<CLIENT-SERVER-TO-SIGNAL-GROUP-MAPPING>
( application_errors )
( composite_type_mappings )
( empty_signal )
mapped_operation_ref
( primitive_type_mappings )
( request_group_ref | response_group_ref )
( sequence_counter )
</CLIENT-SERVER-TO-SIGNAL-GROUP-MAPPING>
mapped_operation_ref ::=
<MAPPED-OPERATION-IREF>
component_prototype_ref
<PORT-PROTOTYPE-REF>ref</PORT-PROTOTYPE-REF>
<OPERATION-REF>ref</OPERATION-REF>
</MAPPED-OPERATION-IREF>
188
Configuration
RTA-RTE V6.2.0
Reference Manual
The <MAPPED-OPERATION-IREF> instance reference contains elements: the component
prototype, the port prototype within the component prototype and the operation within
the interface categorizing the port.
application_errors ::=
<APPLICATION-ERRORS>
*application_error_mapping
</APPLICATION-ERRORS >
application_error_mapping ::=
<APPLICATION-ERROR-MAPPING>
system_signal_ref
</APPLICATION-ERROR-MAPPING>
The <APPLICATION-ERRORS> element is used to provide a signal to carry an error code
from the server back to the client.
empty_signal ::=
<EMPTY-SIGNAL>
system_signal_ref
</EMPTY-SIGNAL>
sequence_counter ::=
<SEQUENCE-COUNTER>
system_signal_ref
</SEQUENCE-COUNTER >
request_group_ref ::=
<REQUEST-GROUP-REF>ref</REQUEST-GROUP-REF >
response_group_ref ::=
<RESPONSE-GROUP-REF>ref</RESPONSE-GROUP-REF >
Either a <REQUEST-GROUP-REF> or a <RESPONSE-GROUP-REF> must be specified in a
mapping (but not both), and for any given operation, there must be mappings containing each of these elements. They identify the signal group used for atomic transmission
of all the arguments and other data associated with a client-server call or response.
The <PRIMITIVE-TYPE-MAPPING> and <COMPOSITE-TYPE-MAPPING> elements are used
to collect signal mappings for the simple and complex arguments, respectively, of a
client-server operation. They include a range of XML elements very similar to those
used for sender-receiver data mappings.
primitive_type_mappings ::=
<PRIMITIVE-TYPE-MAPPING>
*primitive_type_mapping
</PRIMITIVE-TYPE-MAPPING>
primitive_type_mapping ::=
argument_ref
system_signal_ref
The argument_ref reference identifies the argument to which the mapping applies.
Configuration
189
RTA-RTE V6.2.0
Reference Manual
argument_ref ::=
<ARGUMENT-REF>ref</ARGUMENT-REF>
system_signal_ref ::=
<SYSTEM-SIGNAL-REF>ref</SYSTEM-SIGNAL-REF>
A <COMPOSITE-TYPE-MAPPING> element is used to collect signal mappings for complex
arguments (records and arrays) of a client-server operation.
composite_type_mappings ::=
<COMPOSITE-TYPE-MAPPINGS>
*( cs_record_type_mapping | cs_array_type_mapping )
</COMPOSITE-TYPE-MAPPINGS>
Since there can be multiple complex arguments the element encapsulates zero or more
mapping elements—one for each argument.
The <CLIENT-SERVER-RECORD-TYPE-MAPPING> element references the client-server argument and contains the mapping to signals.
cs_record_type_mapping ::=
<CLIENT-SERVER-RECORD-TYPE-MAPPING>
argument_ref
<RECORD-ELEMENT-MAPPINGS>
+cs_record_element_mapping
<RECORD-ELEMENT-MAPPINGS>
</CLIENT-SERVER-RECORD-TYPE-MAPPING>
Each element of the record is mapped using a <CLIENT-SERVER-RECORD-ELEMENT-MAPPING>
element.
cs_record_element_mapping ::=
<CLIENT-SERVER-RECORD-ELEMENT-MAPPING>
( cs_simple_record_element_mapping |
cs_complex_record_element_mapping )
</CLIENT-SERVER-RECORD-ELEMENT-MAPPING>
Record elements can be primitive or complex types. For an element which is a primitive
type the mapping references a single signal.
cs_simple_record_element_mapping ::=
cs_record_element_ref
signal_ref
For record elements that are themselves complex
<CLIENT-SERVER-RECORD-ELEMENT-MAPPING> element is used.
erence for a nested element is ignored.
cs_complex_record_element_mapping ::=
<COMPLEX-TYPE_MAPPING>
( cs_record_type_mapping | cs_array_type_mapping )
</COMPLEX-TYPE_MAPPING>
cs_record_element_ref
190
Configuration
types a nested
The argument ref-
RTA-RTE V6.2.0
Reference Manual
The relevant record element is identified by an <RECORD-ELEMENT-REF> element.
cs_record_element_ref ::=
<RECORD-ELEMENT-REF>
ref
</RECORD-ELEMENT-REF>
Arrays are mapped element-by-element, in a similar way to record, with each element
being mapped to a separate signal:
cs_array_type_mapping ::=
<CLIENT-SERVER-ARRAY-TYPE-MAPPING>
argument_ref
<ARRAY-ELEMENT-MAPPINGS>
+cs_array_element_mapping
</ARRAY-ELEMENT-MAPPINGS>
</CLIENT-SERVER-ARRAY-TYPE-MAPPING>
cs_array_element_mapping ::=
<CLIENT-SERVER-ARRAY-ELEMENT-MAPPING>
( cs_simple_array_element_mapping |
cs_complex_array_element_mapping )
</CLIENT-SERVER-ARRAY-ELEMENT-MAPPING>
cs_simple_array_element_mapping ::=
cs_array_element_ref
signal_ref
cs_complex_array_element_mapping ::=
<COMPLEX-TYPE_MAPPING>
cs_record_type_mapping
</COMPLEX-TYPE_MAPPING>
cs_array_element_ref
Note the restriction here that an array may not contain nested array-type elements.
cs_array_element_ref ::=
<CLIENT-SERVER-ARRAY-ELEMENT-MAPPING>
<INDEXED-ARRAY-ELEMENT>
<ARRAY-ELEMENT-REF>
ref
</ARRAY-ELEMENT-REF>
<INDEX>int</INDEX>
</INDEXED-ARRAY-ELEMENT>
signal_ref
</CLIENT-SERVER-ARRAY-ELEMENT-MAPPING>
An array element reference consists of a software component instance within a composition, a port, and an operation argument. The <INDEX> gives the position of the
mapped element within the array; the <ARRAY-ELEMENT-REF> refers to the type of the
array element, and should therefore have the same value for all the mapped elements
of a given array.
Configuration
191
RTA-RTE V6.2.0
Reference Manual
4.18.3
Software Component to Implementation Mapping
A “software-component implementation mapping” maps software component prototypes to specific implementations. RTA-RTE uses the implementation to determine if a
SWC is implemented as source or object code.
swc_to_impl_mapping ::=
<SW-IMPL-MAPPINGS>
<SWC-TO-IMPL-MAPPING>
short_name
COMPONENT-IMPLEMENTATION-REF>ref</COMPONENT-IMPLEMENTATION-REF>
<COMPONENT-IREFS>
+component_prototype_iref
</COMPONENT-IREFS>
</SWC-TO-IMPL-MAPPING>
</SW-IMPL-MAPPINGS>
A single SWC-to-implementation mapping can associate multiple component instances
with the same implementation.
4.18.4
Software Component to ECU Mapping
A “software-component to ECU” maps software component prototypes to ECU instances.
swc_mappings ::=
<SW-MAPPINGS>
*swc_to_ecu_mapping
<SW-MAPPINGS>
An SWC mapping defines neither the component prototypes nor the ECU instances—
it merely contains references to other elements that associate component prototypes
with ECU instances.
swc_to_ecu_mapping ::=
<SWC-TO-ECU-MAPPING>
short_name
<COMPONENT-IREFS>
+component_prototype_iref
</COMPONENT-IREFS>
ecu_instance_iref
</SWC-TO-ECU-MAPPING>
A single <SWC-TO-ECU-MAPPING> element can map multiple SWC prototypes to an ECU
instance. Each mapped prototype requires a <COMPONENT-IREF> element.
component_prototype_iref ::=
<COMPONENT-IREF>
instance_ref
</COMPONENT-IREF>
The <COMPONENT-IREF> instance reference defines the component prototype to be
mapped and requires at least one <SOFTWARE-COMPOSITION-REF> reference to the
192
Configuration
RTA-RTE V6.2.0
Reference Manual
top level composition, zero or more <COMPONENT-PROTOTYPE-REF> references to component prototypes that form levels within the composition hierarchy and finally one
<TARGET-COMPONENT-PROTOTYPE-REF> that specifies the SWC prototype.
The software-components are mapped to an ECU instance defined via the
<ECU-INSTANCE-REF> element:
ecu_instance_iref ::=
<ECU-INSTANCE-REF>
instance_ref
</ECU-INSTANCE-REF>
The <ECU-INSTANCE-REF> reference defines the ECU instance to which the component
prototypes are mapped.
4.18.5
Software Composition Instance
A “software-component to ECU” mapping within a system description element identifies software component prototypes via a reference to a software composition instance.
sw_compositon ::=
<SOFTWARE-COMPOSITION>
short_name
<SOFTWARE-COMPOSITION-TREF>
ref
</SOFTWARE-COMPOSITION-TREF>
</SOFTWARE-COMPOSITION>
The reference within the <SOFTWARE-COMPOSITION-TREF> refers to the system’s toplevel composition—this is the self-contained (i.e. does not delegate any ports) composition that contains all SWC instances mapped within the System element’s component
mapping.
4.19
ECU Description
The ECU Description is used to define the module configuration for the RTE (as well as
the configuration for many other AUTOSAR modules).
The top-level contain for module configuration within the ECU Description is an XML
element called a <MODULE-CONFIGURATION>. within a module’s configuration an XML
element called a <CONTAINER> is used to describe different configuration aspects.
The type of a module configuration or container element is identified by a
<DEFINITION-REF> element that defines a “path”; for AUTOSAR defined definition references this element contains a path that always starts with /AUTOSAR. A container can
encapsulate other (sub)containers and thus a hierarchy of configuration containers is
formed.
For brevity, within the following section the ‘path’ of the encapsulated containers is
abbreviated such that the common prefix (e.g. /AUTOSAR/Rte) is replaced with ‘...’
when describing containers located at the same hierarchy level.
Configuration
193
RTA-RTE V6.2.0
Reference Manual
4.19.1
OS Module
AUTOSAR OS Configuration occurs within an instance of the container type
/AUTOSAR/Os. RTA-RTE can require access to the defined OS tasks, resources and
events.
If the RTA-RTE RTE generator requires an OS event to be able to schedule
a runnable entity and none is specified in the input then a suitable event is
constructed. See Section 10.2.5 for naming conventions.
4.19.2
RTE Module
Configuration of the RTE module occurs within an instance of the container type
/AUTOSAR/Rte. The RTE configuration container can contain one or more subcontainers:
• .../CommonPublishedInformation—Defines the AUTOSAR version and RTA-RTE
version for which the information within the file is appropriate. The RTA-RTE RTE
generator verifies that the supplied Common Published Information is appropriate.
• .../RTEGeneration—Defines the generation parameters for RTA-RTE including the
operating mode, optimization strategy and whether or not VFB Trace Hooks are
generated.
• .../SwComponentInstance—The parent container for describing configuration of
a SW-C instance. Further sub-containers defines the mapping of one or more
runnable entity instances to OS task(s) and the implementation method to be used
for exclusive areas. The SW-C instance container can optionally describe the association between an software-component instance and its implementation.
• .../CalprmComponentInstance—Disables calibration support for a specified application software-component or calibration component type.
The relationship between containers in the Rte’s module configuration container is described in Figure 4.2.
Container CommonPublishedInformation
Configuration of version information occurs within an instance of the container type
/AUTOSAR/Rte/CommonPublishedInformation.
The Common Published Information container contains eight integer values:
• .../ArMajorVersion—An integer defining the ‘major’ part of the supported AUTOSAR version.
• .../ArMinorVersion—An integer defining the ‘minor’ part of the supported AUTOSAR version.
• .../ArMajorVersion—An integer defining the ‘patch’ revision of the supported
AUTOSAR version.
194
Configuration
RTA-RTE V6.2.0
Reference Manual
Container
/AUTOSAR/Rte
1
Container
…/RteGeneration
0..*
Container
…/CalprmComponentInstance
1
…/CommonPublishedInformation
Container
Sub-container
0..*
Container
…/SwComponentInstance
0..*
…/RunnableEntityMapping
Sub-container
0..*
Sub-container
0..*
…/NVRamAllocation
…/ExclusiveAreaImplementation
Sub-container
0..*
…/RteMeasurementSupport
Figure 4.2: Top-level RTE Configuration Containers
• .../ModuleId—Not used by RTA-RTE.
• .../SwMajorVersion—An integer defining the ‘major’ part of the supported RTARTE release.
• .../SwMinorVersion—An integer defining the ‘minor’ part of the supported RTARTE release.
• .../SwPatchVersion—An integer defining the ‘patch’ revision of the supported
RTA-RTE release.
• .../VendorId—Not used by the RTA-RTE RTE generator.
The supported values for each integer parameter are defined in Section 11.1. If the
CommonPublishedInformation container is present in the input the contained values
are compared against the expected values and an error emitted if inconsistent.
Container RTEGeneration
Configuration of RTE generation parameters occurs within an instance of the container
type /AUTOSAR/Rte/RteGeneration. The RTE generation container can contain one or
more containers:
• .../RteGenerationMode—Defines the generation mode used; acceptable enumeration values are COMPATIBILITY_MODE and VENDOR_MODE.
• .../RteVfbTrace—Enables (non-zero) or disables (zero) creation of VFB trace hook
calls in the generated RTE. Note that even when creation of hook calls is enabled
it remains necessary to enable/disable the use of individual hooks when the RTE is
compiled.
Configuration
195
RTA-RTE V6.2.0
Reference Manual
The generation of VFB trace hooks can be enabled/disabled using either the
--vfb-trace command-line option or via the RTEGeneration container. If the optimization mode is specified both within RTE parameters and on the command-line
the latter specification takes precedence.
The specification of this parameter is optional; if omitted RTA-RTE will create VFB
trace hook calls.
• .../RteOptimizationMode—Defines the optimization strategy for RTE generation;
acceptable enumeration values are “RUNTIME” and “MEMORY”.
The optimization mode can be selected using either the --optimize command-line
option or via the RTEGeneration container. If the optimization mode is specified
both within RTE parameters and on the command-line the latter specification takes
precedence.
The optimization strategy parameter is optional; if omitted RTA-RTE defaults to the
“runtime” strategy.
In addition to the containers common to all AUTOSAR releases described above, the
following additional containers can be included within the RteGeneration container.
• .../RteMeasurementSupport—Enables (“true”) or disables (“false”) measurement support within the generated RTE.
The specification of this parameter is optional; if omitted measurement support
within RTA-RTE is enabled.
• .../RteCalibrationSupport—Defines the global calibration method; acceptable
enumeration values are “NONE”, “SINGLE_POINTERED”, “DOUBLE_POINTERED” and
“INITIALIZED_RAM”.
The calibration method can be selected using either the --calibration-method
command-line option or via the RTEGeneration container. If the calibration method
is specified both within RTE parameters and on the command-line the latter specification takes precedence.
The calibration method parameter is optional; if omitted RTA-RTE defaults to the
“single pointered” method.
The RTE module configuration must contain at most one RTE generation container.
Sub-container RteForceBasicTask
RTA-RTE uses a sub-container within the RteGeneration container to enable the selection of forced-basic semantics (see RTA-RTE User Guide) for individual tasks.
The specification of the RteForceBasicTask container is a custom RTA-RTE
feature and is not part of the AUTOSAR standards.
The RteForceBasicTask sub-container has definition reference /RTARTE/Rte/RteGeneration/RteForceBasicTask and may occur zero or more times within the RTE’s
module configuration
196
Configuration
RTA-RTE V6.2.0
Reference Manual
The RteForceBasicTask sub-container references an OsTask container within the application OS module configuration and switches on or off the forced-basic semantics for
that task by means of a boolean parameter /RTARTE/Rte/RteGeneration/RteForceBasicTask/OverrideValue.
It is an error to specify multiple RteForceBasicTask sub-containers referring to the
same task unless all the containers for the task also specify the same OverrideValue.
An example of this vendor-specific container is shown below. For clarity the RteGeneration parameters have been omitted and the definition refernces shortened.
<CONTAINER>
<SHORT-NAME>...</SHORT-NAME>
<DEFINITION-REF>/AUTOSAR/Rte/RteGeneration</DEFINITION-REF>
<PARAMETER-VALUES>
...
</PARAMETER-VALUES>
<SUB-CONTAINERS>
<CONTAINER>
<SHORT-NAME>...</SHORT-NAME>
<DEFINITION-REF>
/RTARTE/Rte/RteGeneration/RteForceBasicTask
</DEFINITION-REF>
<PARAMETER-VALUES>
<BOOLEAN-VALUE>
<DEFINITION-REF>.../OverrideValue</DEFINITION-REF>
<VALUE>true</VALUE>
</BOOLEAN-VALUE>
</PARAMETER-VALUES>
<REFERENCE-VALUES>
<REFERENCE-VALUE>
<DEFINITION-REF>.../TaskRef</DEFINITION-REF>
<VALUE-REF>/pkg/Os/example_task</VALUE-REF>
</REFERENCE-VALUE>
</REFERENCE-VALUES>
</CONTAINER>
</SUB-CONTAINERS>
</CONTAINER>
The names of RteForceBasicTask sub-containers are not used by RTA-RTE other than
to ensure uniqueness.
Container SwComponentInstance
The /AUTOSAR/Rte/SwComponentInstance container defines the configuration of a single SW-C instance including the mapping of a runnable entity instance to OS tasks and
the specification of exclusive area implementation method.
The SwComponentInstance container can specify one or more sub-containers that define runnable entity mapping, specify how an exclusive area should be implemented or
define NVRAM allocation.
Configuration
197
RTA-RTE V6.2.0
Reference Manual
Component Prototype Selection
The SwComponentInstance container references the appropriate SW-C prototype using SoftwareComponentInstanceRef. This element contains a <VALUE-IREF> element
refering to the software component prototype in the context of its composition.
RTA-RTE requires that the <VALUE-IREF> element contain a set of absolute references
to the SW-C instance (i.e. the component prototype). When a single level exists
in the composition hierachy then the SoftwareComponentInstanceRef can be a single <VALUE-REF>. However when nested compositions are used the reference must
include each level of the nesting as a <CONTEXT-REF> and must terminate with a
<VALUE-REF> that references a component-prototype.
When a /AUTOSAR/Rte/SwComponentInstance container references a service
component it should use a ServiceComponentPrototypeRef rather than a
SoftwareComponentInstanceRef.
The ServiceComponentPrototypeRef is specified as a reference to the component prototype. Service components cannot be present within a nested composition and therefore only a single <XML-TAG> is required.
The SwComponentInstance must specify exactly one SoftwareComponentInstanceRef
or ServiceComponentPrototypeRef.
Implementation Selection
The SwComponentInstance container can optionally reference an implementation element using an .../ImplementationRef. when specified this selects an implementation element to associate with the SW-C instance. The implementation is specified as
an absolute reference.
A SW-C instance can only be associated with a single implementation.
Runnable entity Mapping
Each runnable entity mapping sub-container maps a single RTE Event (instance and
hence triggered runnable entity instance) to a task. Each RunnableEntityMapping
defines the following parameter values:
• .../PositionInTask—The position of the runnable entity within the task (this
must be specified as an unsigned integer).
To prevent ambiguities in runnable ordering, all runnable entities mapped to a task
should have unique positions within the task. The positions specified for runnable
entities within a task need not be contiguous.
• .../RTEEventRef—The RTE Event responsible for activating the runnable entity
name. This must be specified as an absolute reference to the RTE Event within the
SW-C internal behavior definition
198
Configuration
RTA-RTE V6.2.0
Reference Manual
• .../MappedToTaskRef—The OS task to which the runnable entity is mapped. This
must be specified as an absolute reference to the OS Task definition within the OS
configuration container.
• .../OsEventRef—The OS event to be used by the RTA-RTE RTE generator (if required) to schedule the runnable entity.
The specification of an OsEvent is optional. If the RTA-RTE RTE generator
does not require an OsEvent to be used to schedule the runnable then it
will be ignored. If an OsEvent is required but not specified then the RTE
generator will construct a suitable event.
• .../ActivationOffset—The offset (in seconds) from the period. This parameter
is only applicable for TimingEvents.
The input information must contain one runnable entity mapping container for each
RTE Event that starts a runnable entity. There is no need to map RTE Events that do not
trigger a runnable.
Exclusive Area Implementation
As well as runnable entity mapping, the SwComponentInstance container can specify
one or more implementation method specifications.
Each ExclusiveAreaImplementation sub-container specifies the implementation of a
single exclusive area in the context of a SwcInstance. The sub-container provides a
mechanism to specify the implementation method (OS resource or interrupt blocking)
and, if applicable, the OS resource, used for an exclusive area instance.
• .../ExclusiveAreaRef—The exclusive area to which the implementation method
applies.
The referenced exclusive area must be declared within the internal behavior associated with the SW-C instance.
• .../ExclusiveAreaImplMechanism—The implementation method to be used for
the referenced exclusive area. Acceptable enumeration values are: “INTERRUPT_BLOCKING”, “NON_PREEMPTIVE_TASKS”, “OS_RESOURCE” and “COOPERATIVE_RUNNABLE_PLACEMENT”.
If the specification of the implementation method is omitted for a SW-C instance,
RTA-RTE will assume that OS resources should be used.
• .../ExclusiveAreaOsResourceRef—This is an optional, vendor-specific, reference that specifies the OsResource to be used to implement the referenced Exclusive Area.
When present, the .../ExclusiveAreaOsResourceRef must refer to an
OsResource container. If absent, then the default OS resource created by RTARTE is used. If the exclusive area does not require an OS resource, for example it’s
use is optimized away by RTA-RTE, then the parameter is disregarded.
Configuration
199
RTA-RTE V6.2.0
Reference Manual
The DEFINITION-REF of the parameter is /RTARTE/Rte/SwComponentInstance/ExclusiveAreaImplementation/ExclusiveAreaOsResourceRef
Because this is a vendor-specific parameter, its DEFINITION-REF starts
.
/RTARTE/ not /AUTOSAR/
An example of the ExclusiveAreaOsResourceRef parameter is shown
low.
For clarity the standard AUTOSAR definition references for
ExclusiveAreaImplementation have been abbreviated.
bethe
<CONTAINER>
<SHORT-NAME>EAImplementation1</SHORT-NAME>
<DEFINITION-REF>
/AUTOSAR/.../ExclusiveAreaImplementation
</DEFINITION-REF>
<PARAMETER-VALUES>
<ENUMERATION-VALUE>
<DEFINITION-REF>/AUTOSAR/.../ExclusiveAreaImplMechanism</DEFINITIONREF>
<VALUE>OS_RESOURCE</VALUE>
</ENUMERATION-VALUE>
</PARAMETER-VALUES>
<REFERENCE-VALUES>
<REFERENCE-VALUE>
<DEFINITION-REF>/AUTOSAR/.../ExclusiveAreaRef</DEFINITION-REF>
<VALUE-REF>/pkg/ibswc/cr1</VALUE-REF>
</REFERENCE-VALUE>
<REFERENCE-VALUE>
<DEFINITION-REF>
/RTARTE/Rte/SwComponentInstance/ExclusiveAreaImplementation/
ExclusiveAreaOsResourceRef
</DEFINITION-REF>
<VALUE-REF>/pkg/Os/MyResource</VALUE-REF>
</REFERENCE-VALUE>
</REFERENCE-VALUES>
</CONTAINER>
NVRam Allocation
As well as runnable entity mapping, the SwComponentInstance container can specify
one or more NVRAM allocation specifications.
Each NVRamAllocation sub-container specifies the implementation of a single exclusive area and defines the following parameter values:
• .../RamBlockLocationSymbol—The name (C identifier) associated with the
NVRAM block.
• .../RomBlockLocationSymbol—The name (C identifier) of the ROM initializer associated with the NVRAM block.
This parameter is not used by this release of RTA-RTE.
200
Configuration
RTA-RTE V6.2.0
Reference Manual
• .../SwNvRamMappingReference—An absolute reference to the NVRAM mapping
(within the SW-C instances internal behavior).
• .../NvmBlockRef—Associated NVRAM block definition (within the ECUC configuration for the NVRAM manager)
Calibration Disable
RTA-RTE uses the CalprmComponentInstance container to disable calibration support
for a specified SW-C type.
Each CalprmComponentInstance container disables calibration support for a single AUTOSAR application SW-C or Calibration component type.
The container encapsulates a Boolean parameter and references a SW-C type. The
parameter determines whether calibration support is enabled (“true”) or disabled
(“false”) for the referenced SW-C.
• .../CalprmComponentInstanceRef—The SW-C type, specified as an absolute reference.
• .../CalibrationSupportEnabled—Boolean indicating whether or not calibration
support is enabled.
Calibration support is enabled by default and therefore a CalprmComponentInstance container is only necessary to disable support to
a specified SW-C type.
The RTE Generation parameter RteCalibrationSupport can be used to globally disable calibration support by selecting the calibration method “none”.
4.20
Vendor Specific XML Extensions
There are no vendor-specific XML extensions.
4.21
Post-build
The following configuration options are available after an RTE has been generated.
4.21.1
Atomicity
The generated RTE uses different mechanisms for ensuring that data reads and writes
are atomic depending on the actual size of the data item. The atomicity mechanism
can be configured, after the RTE is generated (post-build), to disable code generation
for certain data types when it is known that the underlying hardware already provides
the required atomicity, e.g. for 8-bit data types.
• RTE_<SIZE>_ATOMIC—if defined, the generated RTE assumes that integer variables
of size <SIZE> can be read and/or written atomically.
Configuration
201
RTA-RTE V6.2.0
Reference Manual
• RTE_<SIZE>_NONATOMIC—if defined, the generated RTE assumes that integer variables of size <SIZE> cannot be read and/or written atomically.
Where <SIZE> corresponds to the data item size in bits. Valid values are 8BIT, 16BIT,
32BIT, 64BIT, FLOAT32, FLOAT64 and BOOLEAN.
The default of the generated RTE is to assume that only 8-bit integers can be read/written atomically and that all other types must be protected. If the default behavior is
not required then definitions can be placed on the command line when invoking the C
compiler to modify compilation of Rte.c and SWC implementations, for example:
$(CC) --DRTE_16BIT_ATOMIC --DRTE_32BIT_ATOMIC Rte.c
4.22
Variability
Version 5.1 of RTA-RTE introduces support for pre-build variability. Variability allows
elements of the configuration to be enabled or disabled, or values in the configuration
to be written as expressions rather than literal numbers. The containers for which RTARTE supports variability are listed in subsection 4.22.1 whilst the AUTOSAR Formula
Language (AFL) is described in subsection 4.22.2.
4.22.1
Containers Supporting Pre-Build Variability
The following table lists the containers which RTA-RTE checks for pre-build variation
during the processing of input XML.
Container
APPLICATION-PRIMITIVE-DATA-TYPE
APPLICATION-RECORD-DATA-TYPE
APPLICATION-SW-COMPONENT-TYPE
ARRAY-SIZE
ASYNCHRONOUS-SERVER-CALL-POINT
ASYNCHRONOUS-SERVER-CALL-RESULT-POINT
ASYNCHRONOUS-SERVER-CALL-RETURNS-EVENT
BACKGROUND-EVENT
BSW-BACKGROUND-EVENT
BSW-CALLED-ENTITY
BSW-EXTERNAL-TRIGGER-OCCURRED-EVENT
BSW-IMPLEMENTATION
BSW-INTERNAL-TRIGGER-OCCURRED-EVENT
BSW-INTERNAL-TRIGGERING-POINT
BSW-INTERRUPT-ENTITY
BSW-MODE-RECEIVER-POLICY
BSW-MODE-SENDER-POLICY
202
Configuration
RTA-RTE V6.2.0
Reference Manual
Container
BSW-MODE-SWITCH-EVENT
BSW-MODE-SWITCHED-ACK-EVENT
BSW-MODULE-DESCRIPTION
BSW-MODULE-ENTRY
BSW-SCHEDULABLE-ENTITY
BSW-TIMING-EVENT
BSW-TRIGGER-DIRECT-IMPLEMENTATION
CALIBRATION-PARAMETER-VALUE-SET
CLIENT-SERVER-ARRAY-ELEMENT-MAPPING
CLIENT-SERVER-ARRAY-TYPE-MAPPING
CLIENT-SERVER-INTERFACE
CLIENT-SERVER-INTERFACE-MAPPING
CLIENT-SERVER-OPERATION
CLIENT-SERVER-OPERATION-MAPPING
CLIENT-SERVER-PRIMITIVE-TYPE-MAPPING
CLIENT-SERVER-RECORD-ELEMENT-MAPPING
CLIENT-SERVER-RECORD-TYPE-MAPPING
CLIENT-SERVER-TO-SIGNAL-GROUP-MAPPING
COMPLEX-DEVICE-DRIVER-SW-COMPONENT-TYPE
COMPLEX-TYPE-MAPPING
COMPOSITION-SW-COMPONENT-TYPE
COMPU-METHOD
CONSTANT-SPECIFICATION
CONSTANT-SPECIFICATION-MAPPING
CONSTANT-SPECIFICATION-MAPPING-SET
DATA-CONSTR
DATA-PROTOTYPE-MAPPING
DATA-RECEIVE-ERROR-EVENT
DATA-RECEIVED-EVENT
DATA-SEND-COMPLETED-EVENT
DATA-TYPE-MAPPING-SET
DATA-TYPE-POLICY
DATA-WRITE-COMPLETED-EVENT
ECU
ECU-ABSTRACTION-SW-COMPONENT-TYPE
ECU-INSTANCE
ECU-SW-COMPOSITION
Configuration
203
RTA-RTE V6.2.0
Reference Manual
Container
ECUC-CONTAINER-VALUE
ECUC-VALUE-COLLECTION
EXCLUSIVE-AREA
EXTERNAL-TRIGGER-OCCURRED-EVENT
EXTERNAL-TRIGGERING-POINT
FILTER
FLAT-INSTANCE-DESCRIPTOR
FLAT-MAP
I-SIGNAL
I-SIGNAL-GROUP
I-SIGNAL-TO-I-PDU-MAPPING
IMPL-INIT-VALUE
IMPLEMENTATION-DATA-TYPE
IMPLEMENTATION-DATA-TYPE-ELEMENT
INCLUDED-DATA-TYPE-SET
INDEX
INDEXED-ARRAY-ELEMENT
INTERNAL-TRIGGER-OCCURRED-EVENT
INTERNAL-TRIGGERING-POINT
IS-REENTRANT y?
IS-SERVICE y?
MODE-ACCESS-POINT
MODE-DECLARATION-GROUP
MODE-DECLARATION-GROUP-PROTOTYPE
MODE-GROUP
MODE-INTERFACE-MAPPING
MODE-MAPPING
MODE-REQUEST-TYPE-MAP
MODE-SWITCH-INTERFACE
MODE-SWITCH-POINT
MODE-SWITCHED-ACK
MODE-SWITCHED-ACK-EVENT
NETWORK-REPRESENTATION
NV-BLOCK-DATA-MAPPING
NV-BLOCK-DESCRIPTOR
NV-BLOCK-SW-COMPONENT-TYPE
NV-DATA-INTERFACE
204
Configuration
RTA-RTE V6.2.0
Reference Manual
Container
OPERATION-INVOKED-EVENT
P-PORT-PROTOTYPE
PACKING-BYTE-ORDER
PARAMETER-ACCESS
PARAMETER-DATA-PROTOTYPE
PARAMETER-INTERFACE
PARAMETER-SW-COMPONENT-TYPE
PER-INSTANCE-MEMORY
PHYSICAL-DIMENSION
PORT-API-OPTION
QUEUED-RECEIVER-COM-SPEC
R-PORT-PROTOTYPE
RAM-BLOCK
ROOT-SW-COMPOSITION-PROTOTYPE
RUNNABLE-ENTITY
SENDER-REC-ARRAY-ELEMENT-MAPPING
SENDER-REC-ARRAY-TYPE-MAPPING
SENDER-REC-RECORD-ELEMENT-MAPPING
SENDER-REC-RECORD-TYPE-MAPPING
SENDER-RECEIVER-INTERFACE
SENDER-RECEIVER-TO-SIGNAL-GROUP-MAPPING
SENDER-RECEIVER-TO-SIGNAL-MAPPING
SENSOR-ACTUATOR-SW-COMPONENT-TYPE
SERVER-ARGUMENT-IMPL-POLICY
SERVICE-COMPONENT-PROTOTYPE
SERVICE-SW-COMPONENT-TYPE
START-POSITION
SUPPORTS-ASYNCHRONOUS-MODE-SWITCH
SW-ADDR-METHOD
SW-BASE-TYPE
SW-COMPONENT-PROTOTYPE
SW-DATA-DEF-PROPS-CONDITIONAL
SW-SYSTEMCONST
SW-SYSTEMCONST-VALUE
SW-SYSTEMCONSTANT-VALUE-SET
SWC-BSW-MAPPING
SWC-BSW-RUNNABLE-MAPPING
Configuration
205
RTA-RTE V6.2.0
Reference Manual
Container
SWC-BSW-SYNCHRONIZED-MODE-GROUP-PROTOTYPE
SWC-BSW-SYNCHRONIZED-TRIGGER
SWC-IMPLEMENTATION
SWC-MODE-SWITCH-EVENT
SWC-SERVICE-DEPENDENCY
SWC-TO-ECU-MAPPING
SWC-TO-IMPL-MAPPING
SYNCHRONOUS-SERVER-CALL-POINT
SYSTEM
SYSTEM-MAPPING
SYSTEM-SIGNAL
SYSTEM-SIGNAL-GROUP
TASK
TEXT-TABLE-MAPPING
TEXT-TABLE-VALUE-PAIR
TIMING-EVENT
TRIGGER
TRIGGER-INTERFACE
TRIGGER-INTERFACE-MAPPING
TRIGGER-MAPPING
TYPE
TYPE-MAPPING
UNIT
USED-DATA-ELEMENT
V
VARIABLE-ACCESS
VARIABLE-AND-PARAMETER-INTERFACE-MAPPING
VARIABLE-DATA-PROTOTYPE
4.22.2
AUTOSAR Formula Language
Whilst the AUTOSAR Formula Language (AFL) is described fully in Section 4.8 of the
AUTOSAR Generic Structure Template, the manner in which it is integrated into the
XML is not. Here are some examples of how expressions are written.
Simple Number
...
<VARIATION-POINT>
<SHORT-LABEL>vpbe1Pct</SHORT-LABEL>
<SW-SYSCOND BINDING-TIME=’CODE-GENERATION-TIME’>1</SW-SYSCOND>
206
Configuration
RTA-RTE V6.2.0
Reference Manual
</VARIATION-POINT>
...
In this example, the result of the <SW-SYSCOND> expression is simply the number 1.
Simple Expression
...
<VARIATION-POINT>
<SHORT-LABEL>vpbe1Pct</SHORT-LABEL>
<SW-SYSCOND BINDING-TIME=’CODE-GENERATION-TIME’>1 + 4</SW-SYSCOND>
</VARIATION-POINT>
...
In this example, the result of the <SW-SYSCOND> expression is the number 5 - the result
of adding 1 and 4.
Other arithmetic operators are available ( +, -, *, / ).
Cross-Reference
...
<AR-PACKAGE>
<SHORT-NAME>system_constants</SHORT-NAME>
<ELEMENTS>
<SW-SYSTEMCONST>
<SHORT-NAME>switch_on</SHORT-NAME>
</SW-SYSTEMCONST>
<SW-SYSTEMCONSTANT-VALUE-SET>
<SHORT-NAME>scvs</SHORT-NAME>
<SW-SYSTEMCONSTANT-VALUES>
<SW-SYSTEMCONST-VALUE>
<SW-SYSTEMCONST-REF DEST=’SW-SYSTEMCONST’>/system_constants/
switch_on</SW-SYSTEMCONST-REF>
<VALUE>1</VALUE>
</SW-SYSTEMCONST-VALUE>
</SW-SYSTEMCONSTANT-VALUES>
</SW-SYSTEMCONSTANT-VALUE-SET>
</ELEMENTS>
</AR-PACKAGE>
...
<VARIATION-POINT>
<SHORT-LABEL>vpbe1Pct</SHORT-LABEL>
<SW-SYSCOND BINDING-TIME=’CODE-GENERATION-TIME’>
<SYSC-REF DEST=’SW-SYSTEMCONST’>/system_constants/switch_on</SYSC-REF
>
</SW-SYSCOND>
</VARIATION-POINT>
...
In this example, the result of the <SW-SYSCOND> expression is the number 1 - since that
is the value of the system constant (switch_on) which it references.
Configuration
207
RTA-RTE V6.2.0
Reference Manual
<VALUE>s contained within <SW-SYSTEMCONST>s are themselves expressions, and can
therefore reference other <SW-SYSTEMCONST>s.
Boolean Tests
...
<AR-PACKAGE>
<SHORT-NAME>system_constants</SHORT-NAME>
<ELEMENTS>
<SW-SYSTEMCONST>
<SHORT-NAME>num_cylinders</SHORT-NAME>
</SW-SYSTEMCONST>
<SW-SYSTEMCONSTANT-VALUE-SET>
<SHORT-NAME>scvs</SHORT-NAME>
<SW-SYSTEMCONSTANT-VALUES>
<SW-SYSTEMCONST-VALUE>
<SW-SYSTEMCONST-REF DEST=’SW-SYSTEMCONST’>/system_constants/
num_cylinders</SW-SYSTEMCONST-REF>
<VALUE>6</VALUE>
</SW-SYSTEMCONST-VALUE>
</SW-SYSTEMCONSTANT-VALUES>
</SW-SYSTEMCONSTANT-VALUE-SET>
</ELEMENTS>
</AR-PACKAGE>
...
<VARIATION-POINT>
<SHORT-LABEL>vpbe1Pct</SHORT-LABEL>
<SW-SYSCOND BINDING-TIME=’CODE-GENERATION-TIME’>
<SYSC-REF DEST=’SW-SYSTEMCONST’>/system_constants/num_cylinders</SYSC
-REF> == 4
</SW-SYSCOND>
</VARIATION-POINT>
...
In this example, the expression compares the value of the num_cylinders
<SW-SYSTEMCONST> against the literal 4. The result of this comparison is the number 0,
indicating FALSE.
Such an expression might be used to enable configuration which is only relevant for
four-cylinder engines.
VALUE substitution
...
<AR-PACKAGE>
<SHORT-NAME>system_constants</SHORT-NAME>
<ELEMENTS>
<SW-SYSTEMCONST>
<SHORT-NAME>num_cylinders</SHORT-NAME>
</SW-SYSTEMCONST>
<SW-SYSTEMCONSTANT-VALUE-SET>
<SHORT-NAME>scvs</SHORT-NAME>
<SW-SYSTEMCONSTANT-VALUES>
208
Configuration
RTA-RTE V6.2.0
Reference Manual
<SW-SYSTEMCONST-VALUE>
<SW-SYSTEMCONST-REF DEST=’SW-SYSTEMCONST’>/system_constants/
num_cylinders</SW-SYSTEMCONST-REF>
<VALUE>6</VALUE>
</SW-SYSTEMCONST-VALUE>
</SW-SYSTEMCONSTANT-VALUES>
</SW-SYSTEMCONSTANT-VALUE-SET>
</ELEMENTS>
</AR-PACKAGE>
...
<IMPLEMENTATION-DATA-TYPE>
<SHORT-NAME>Array1</SHORT-NAME>
<CATEGORY>ARRAY</CATEGORY>
<SUB-ELEMENTS>
<IMPLEMENTATION-DATA-TYPE-ELEMENT>
<SHORT-NAME>Array1_element</SHORT-NAME>
<CATEGORY>VALUE</CATEGORY>
<ARRAY-SIZE BINDING-TIME="CODE-GENERATION-TIME"><SYSC-REF DEST="SWSYSTEMCONST">/system_constants/num_cylinders</SYSC-REF></ARRAYSIZE>
<ARRAY-SIZE-SEMANTICS>FIXED-SIZE</ARRAY-SIZE-SEMANTICS>
...
In this example, the value of a <SW-SYSTEMCONST> is used as a <VALUE> in the definition
of an array-type.
The result of the <SW-SYSTEMCONST> might be combined in an arithmetic expression:
...
<IMPLEMENTATION-DATA-TYPE>
<SHORT-NAME>Array1</SHORT-NAME>
<CATEGORY>ARRAY</CATEGORY>
<SUB-ELEMENTS>
<IMPLEMENTATION-DATA-TYPE-ELEMENT>
<SHORT-NAME>Array1_element</SHORT-NAME>
<CATEGORY>VALUE</CATEGORY>
<ARRAY-SIZE BINDING-TIME="PRE-COMPILE-TIME"><SYSC-REF
DEST="SW-SYSTEMCONST">/system_constants/num_cylinders</SYSC-REF> *
2</ARRAY-SIZE>
<ARRAY-SIZE-SEMANTICS>FIXED-SIZE</ARRAY-SIZE-SEMANTICS>
...
Here, the number of elements in the array is twice the number of cylinders. Since the
array size has a BINDING-TIME of PRE-COMPILE-TIME the value is also emitted as a
Condition-Value-Macro in the Configuration header file (rte_sws_6541).
4.23
Support for the atpSplitable Stereotype
Certain containers within the input XML contain aggregates which are marked as ’splittable’ (i.e. elements of the aggregations can exist in multiple input files - marked as
atpSplitable within the Autosar specifications). RTA-RTE now supports all relevant
splittable aggregates.
Configuration
209
RTA-RTE V6.2.0
Reference Manual
The unsupported (and irrelevant to RTA-RTE) splittable containers are as follows:
• AliasNameSet.AliasNames
• ApplicationSwComponentType.SwComponentDocumentations
• CanCluster.PhysicalChannels
• CanPhysicalChannel.FrameTriggerings
• CanPhysicalChannel.ISignalTriggerings
• CanPhysicalChannel.PduTriggerings
• ComplexDeviceDriverSwComponentType.SwComponentDocumentations
• EcuAbstractionSwComponentType.SwComponentDocumentations
• EndToEndProtection.EndToEndProfile
• EndToEndProtection.EndToEndProtectionISignalIPdus
• EndToEndProtection.EndToEndProtectionVariablePrototypes
• EndToEndProtectionSet.EndToEndProtections
• EthernetPhysicalChannel.FrameTriggerings
• EthernetPhysicalChannel.ISignalTriggerings
• EthernetPhysicalChannel.PduTriggerings
• FlexrayCluster.PhysicalChannels
• FlexrayPhysicalChannel.FrameTriggerings
• FlexrayPhysicalChannel.ISignalTriggerings
• FlexrayPhysicalChannel.PduTriggerings
• LinCluster.PhysicalChannels
• LinPhysicalChannel.FrameTriggerings
• LinPhysicalChannel.ISignalTriggerings
• LinPhysicalChannel.PduTriggerings
• NvBlockSwComponentType.SwComponentDocumentations
• ParameterSwComponentType.SwComponentDocumentations
• SensorActuatorSwComponentType.SwComponentDocumentations
• ServiceProxySwComponentType.SwComponentDocumentations
210
Configuration
RTA-RTE V6.2.0
Reference Manual
• ServiceSwComponentType.SwComponentDocumentations
• TtCanPhysicalChannel.FrameTriggerings
• TtCanPhysicalChannel.ISignalTriggerings
• TtCanPhysicalChannel.PduTriggerings
• TtcanCluster.PhysicalChannels
Configuration
211
RTA-RTE V6.2.0
Reference Manual
5
RTE Conventions
5.1
Name Space
All symbols (e.g. function names, global variables, etc.) created by the RTA-RTE RTE
generator that are visible within the global namespace use either the RTE prefix (for
definitions), Rte (variables, functions names and other symbols) or rte (some generated files).
To prevent clashes with symbols created by the RTE generator, application
software components should not create symbols in the global namespace
using the prefix rte (irrespective of case).
The generated RTE is designed to work with different components written in different
source languages and therefore does not use language specific features, such as C++
namespaces, to ensure symbol name uniqueness. A component can, however, use
language specific features to ensure unique local symbols.
5.2
Software-Component Naming
RTA-RTE does not impose any naming convention on software-components over and
above the standard AUTOSAR restrictions:
• The RTE/Rte namespace is reserved exclusively for use by RTA-RTE generated symbols.
• Software-component names must only contain characters that are valid both for
C-identifiers and for filenames.
This restriction exists since the name is used to construct symbols within the generated RTE (e.g. component data structure instance name) and the name of the
application header file for the software component.
• The names of software component names must be unique.
An application header file is created for each software component type and therefore type names must be globally unique.
212
RTE Conventions
RTA-RTE V6.2.0
Reference Manual
6
RTE API Reference
The functions described in this section are organized by RTE API name as used by C and
C++ software components. The API mapping implemented in the application header file
used by a software component hides from the software component programmer the
need to be aware of the steps taken by the RTE generator to ensure that the generated
API functions have unique names.
6.1
API Parameter Passing
The mechanism by which the parameters are passed to the RTE by API calls and from
the RTE to runnable entities depends on the parameter class and the type of the parameter being passed.
Parameters are divided into two types:
• Primitive Types – AUTOSAR primitive types excluding strings, user defined enumeration types
• Complex Types – AUTOSAR string types, user defined record and array types,
Class
Semantics
Primitive Type
Complex Type
IN
Read-only
by Value
by Reference
IN/OUT
Read-Write
by Reference
by Reference
OUT
Write-only
by Reference
by Reference
Table 6.1: RTA-RTE Parameter Passing Conventions
6.2
Data Types
This section defines the RTA-RTE specific data types used by the RTE API. This section
does not describe the pre-defined AUTOSAR basic software data types nor does it define
how additional AUTOSAR data types can be configured in the XML.
6.2.1
Rte_Instance
A software component instance within an ECU is an instance of a particular component
type. Multiple instances of the same component type can be mapped to an ECU instance and hence a mechanism is required to disambiguate access – for which the RTE
API uses an instance handle.
The RTE API uses component-specific instance handles defined using the typedef
Rte_Instance to provide an identifier for a component instance. All components of
the same type can share the same Rte_Instance type definition.
For ease of use the name of the instance handle type remains the same for all components, even though the underlying types are different, since the actual type definition
is private to the component. This feature relies on the direct equivalence in C/C++ beRTE API Reference
213
RTA-RTE V6.2.0
Reference Manual
tween the typedef and the underlying type.
The instance handle is omitted from the RTE API when an AUTOSAR softwarecomponent is declared as singly instantiated in the SW-C description.
6.2.2
Std_ReturnType
The Std_ReturnType type defines the “status” and “error” values returned by RTE API
functions. The following values are defined:
• RTE_E_OK
• RTE_E_INVALID
• RTE_E_LOST_DATA
• RTE_E_MAXAGE_EXCEEDED
• RTE_E_COM_STOPPED
• RTE_E_TIMEOUT
• RTE_E_LIMIT
• RTE_E_NO_DATA
• RTE_E_TRANSMIT_ACK
• RTE_E_NEVER_RECEIVED
• RTE_E_UNCONNECTED
• RTE_E_IN_EXCLUSIVE_AREA
• RTE_E_SEG_FAULT
• SCHM_E_OK
• SCHM_E_LIMIT
• SCHM_E_NO_DATA
• SCHM_E_TRANSMIT_ACK
• SCHM_E_IN_EXCLUSIVE_AREA
6.2.3
Port Handles
RTA-RTE creates a port handle type for each interface that is used to categorize a port
on a software-component where the port has the indirect API enabled1 .
1
The enabling can be explicit through use of a port API option or implicit when the SWC type supports
multiple instantiation
214
RTE API Reference
RTA-RTE V6.2.0
Reference Manual
A port handle type is used in conjunction with the Rte_Ports and Rte_NPorts APIs to
support iteration over similarly typed ports.
The name of the port handle type is formed as follows:
Rte_PortHandle_<interface>_<P/R>
Where <interface> is the interface name typing the port and “P”/”R” is literal text
indicating whether the port requires or provides the interface.
If the same interface is used to type both required and provided ports then
two port handle types are created. The different port handle types are distinguished by the P/R suffix.
The port handle type is written to the software-components application header file and
therefore is uniquely defined for each component type.
6.3
Rte_Call
Std_ReturnType
Rte_Call_<p>_<o>([IN Rte_Instance <instance>,]
[IN|INOUT|OUT] param_1, ...
[IN|INOUT|OUT] param_n)
Where <p> is the port name and <o> the operation within the client-server interface
that categorizes the port.
6.3.1
Description
API call used by a client to initiate a client-server communication. The Rte_Call API is
used for both synchronous and asynchronous calls.
The Rte_Call API includes zero or more IN, IN/OUT and OUT parameters:
• IN parameters are passed by value for primitive data types and by reference for all
other types.
• OUT parameters are always passed by reference.
• IN/OUT parameters are passed by value when they are primitive data types and
the call is asynchronous and by reference for all other cases.
6.3.2
Return Values
The return value is used to indicate errors detected by the RTE during execution of the
Rte_Call call and, for synchronous communication, application errors returned from
execution of the server.
RTE_E_OK – The call completed successfully.
RTE API Reference
215
RTA-RTE V6.2.0
Reference Manual
RTE_E_TIMEOUT (Synchronous inter-task and inter-ECU only) – No reply was received
within the configured timeout.
RTE_E_COM_STOPPED – A communications error occurred – the data has not been
successfully passed to the communication service.
RTE_E_LIMIT – Multiple asynchronous client-server communications to the same
server are attempted.
Application error – A synchronous client-server can, optionally, return an application
error. The name and values of applications errors are defined within the port’s
interface.
6.3.3
Notes
For intra-task communication, or inter-task communication to a “pure” server, the RTE
API Rte_Call may be elided completely and the call further mapped to a direct function
call of the server’s runnable entity.
A synchronous Rte_Call API is generated if a runnable entity within a softwarecomponent’s internal behavior includes a SynchronousCallPoint specification.
An asynchronous Rte_Call API is generated if a a runnable entity within a softwarecomponent’s internal behavior includes a AsynchronousCallPoint specification.
The OUT parameters are omitted for an asynchronous call since they are only required
to collect the result (when using Rte_Result).
6.3.4
Example
Consider a required port, ra, containing an operation op1 that takes a single IN integer
argument. The following calls can then be made:
SInt16 a = 23;
Std_ReturnType e = Rte_Call_ra_op1(self, a);
if (e == RTE_E_OK)
{
/* call succeeded */
}
6.4
Rte_Prm
<data type> const
Rte_Prm_<port>_<name>([IN Rte_Instance <Instance>])
216
RTE API Reference
RTA-RTE V6.2.0
Reference Manual
Where <name> is the name of the calibration element to access and <port> the name
of the require port name(which must be categorized by a calibration interface).
6.4.1
Description
The Rte_Prm API provides access to calibration data within calibration components.
Multiple software-component instances can access the same calibration data provided
by an instance of a calibration component.
6.4.2
Return Values
The return value is typed according to the type of the configuration data. For primitive
data types the value is returned however for complex types a pointer to the calibration
data is returned.
From the perspective of an application software component calibration data is considered to be read-only and should not be altered.
6.4.3
Notes
A Rte_Prm API is created for each calibration prototype in the calibration interface.
The --calibration-instantiation option means that RTA-RTE can either import calibration data declared by the user in an external module or can instantiate memory
for the calibration data. Due to deficiencies in the AUTOSAR XML input RTA-RTE does
not create the calibration data – see Section 10.5 and therefore the initialization of
the instantiated memory must be performed by the user before access by softwarecomponents.
6.4.4
Example
FUNC(void, RTE_APPL_CODE)
tt1(Rte_Instance self)
{
UInt16 abc = Rte_Prm_port_abc(self);
}
6.5
Rte_CData
<data type> const
Rte_CData_<name>([IN Rte_Instance <Instance>])
Where <name> is the name of the calibration element.
6.5.1
Description
The Rte_CData API provides access to per-instance and shared calibration parameters declared within a software component. All instances of a component type access
the same data for shared parameters whereas each accesses a unique copy for perinstance parameters.
RTE API Reference
217
RTA-RTE V6.2.0
Reference Manual
6.5.2
Return Values
The return value is typed according to the type of the configuration data. For primitive
data types the value is returned however for complex types a pointer to the calibration
data is returned.
6.5.3
Notes
A Rte_CData API is created for each per-instance or shared calibration element.
RTA-RTE does not create the calibration data – see Section 10.5. The actual calibration
data must be declared by the user in an external module.
6.5.4
Example
FUNC(void, RTE_APPL_CODE)
tt1(Rte_Instance self)
{
UInt16 abc = Rte_CData_abc(self);
}
6.6
Rte_Enter
Std_ReturnType
Rte_Enter_<area>([IN Rte_Instance <instance>])
Where <area> is the exclusive area name.
6.6.1
Description
The Rte_Enter API call is invoked by an application software component to define the
start of an exclusive area. The name of the exclusive area is included as part of the call
name.
All instances of a component are independent and therefore the scope of a exclusive
area extends only to the runnable entities within each instance of a component. When
a runnable entity has ‘entered’ an exclusive area no other runnable entity in the component instance can enter the area until the first runnable entity has invoked Rte_Exit.
6.6.2
Return Values
RTE_E_OK – The exclusive area was entered successfully.The underlying implementation of explicit exclusive areas uses OS resources. Within the AUTOSAR OS it is
not possible for a resource lock to fail and therefore neither can the Rte_Enter
API.
6.6.3
Notes
The Rte_Enter API call is created by RTA-RTE when a runnable entity declares that it
“can enter” an exclusive area.
218
RTE API Reference
RTA-RTE V6.2.0
Reference Manual
The RTE generator will ensure that the API expands to a null macro when possible – for
example when all accessing runnable entities are mapped to the same task or mapped
to tasks that cannot preempt.
The implementation of the exclusive area will depend the implementation strategy
specified in the ECU description file. If no strategy is specified the default is “Os resource”.
It is not valid when using the AUTOSAR OS to wait on an OS event when
one or more resources are locked. Application software components should
therefore avoid invoking RTE APIs that may block, including synchronous
client-server calls, when an exclusive area is locked.
It is not valid when using the AUTOSAR OS to invoke any OS API when interrupts are locked. RTA-RTE uses AUTOSAR OS APIs within RTE API calls and
hence application software components must exercise caution before invoking any RTE API call when an exclusive area that uses “interrupt blocking” is
locked.
Invocations of Rte_Enter (and Rte_Exit) may be nested as long as areas are exited in
the reverse order they were entered. When “interrupt blocking” is used as an implementation strategy API calls should be avoided when running inside the exclusive area
to avoid problems with missed task activations.
RTA-RTE supports selection of an existing OS resource to be used to implement an exclusive area using the vendor-specific ExclusiveAreaOsResourceRef parameter (see
4.19.2)
6.6.4
Example
Consider an exclusive area “A” to which a runnable declares “can enter” access. A
component can enter the area as follows:
Rte_Enter_A(self);
6.7
Rte_Exit
Std_ReturnType
Rte_Exit_<area>([IN Rte_Instance <instance>])
Where <area> is the exclusive area name.
6.7.1
Description
The Rte_Exit API call is invoked by an application software component to define the
end of an exclusive area. The name of the exclusive area is part of the API call name.
All instances of a component are independent and therefore the scope of a exclusive
area extends only to the runnable entities within each instance of a component. When
a runnable entity has ‘entered’ an exclusive area no other runnable entity in the comRTE API Reference
219
RTA-RTE V6.2.0
Reference Manual
ponent instance can enter the area until the first runnable entity has invoked Rte_Exit.
6.7.2
Return Values
RTE_E_OK – The exclusive area was exited successfully.
6.7.3
Notes
The Rte_Exit API call is created by RTA-RTE when a runnable entity declares that it
“can enter” an exclusive area.
The RTE generator will ensure that the API expands to a null macro when possible – for
example when all accessing runnable entities are mapped to the same task or mapped
to tasks that cannot preempt.
Invocations of Rte_Enter (and Rte_Exit) may be nested as long as areas are exited in
the reverse order they were entered.
6.7.4
Example
Consider an exclusive area “A” to which a runnable has “can enter” access. Having
entered the area using Rte_Enter, a component can exit the area as follows:
Rte_Exit_A(self);
6.8
Rte_IFeedback
Std_ReturnType
Rte_IFeedback_<re>_<port>_<item>([IN Rte_Instance <inst>])
Where <re> is the accessing runnable entity name, <port> is the port name and <item>
the data element within the sender-receiver interface categorizing the port.
6.8.1
Description
The Rte_IFeedback API call provides access to transmission acknowledgement notifications for a sender-receiver communication. Unlike the Rte_Feedback API the API is
always non-blocking.
The Rte_IFeedback API takes no parameters other than the instance handle since the
return value is used to indicate either the success or failure of the API call and the
feedback status.
6.8.2
Return Values
RTE_E_NO_DATA – No data (feedback information) was available and no other error
occurred when the feedback read was attempted.
RTE_E_UNCONNECTED – Unconnected provider.
RTE_E_TRANSMIT_ACK – A “transmission acknowledgement” has been received.
This return value indicates no error was detected during execution of the API call.
220
RTE API Reference
RTA-RTE V6.2.0
Reference Manual
6.8.3
Notes
Transmission acknowledgement is enabled for a provided variableDataPrototype by the
presence of an AcknowledgementRequest with type transmission.
A non-blocking API is created for a provided variableDataPrototype if acknowledgement
is enabled and a DataWriteAccess references the variableDataPrototype or a DataWriteCompletedEvent references the runnable and the variableDataPrototype.
6.8.4
Example
Consider a provided port, pa, containing a data element val of type SInt16 that is
specified using the SUCCESS element accessed from runnable re1. The following calls
can then be made:
Rte_Write_pa_val(self, 23);
if (Rte_IFeedback_re1_pa_val(self) == RTE_E_TRANSMIT_ACK)
{
/* Transmit okay */
}
6.9
Rte_Feedback / Rte_SwitchAck
Std_ReturnType
Rte_Feedback_<port>_<item>([IN Rte_Instance <inst>])
Or
Std_ReturnType
Rte_SwitchAck_<port>_<mode>([IN Rte_Instance <inst>])
Where <port> is the port name, <item> the data element within the sender-receiver
interface categorizing the port and <mode> the mode declaration group prototype within
the sender-receiver interface categorizing the port.
6.9.1
Description
The Rte_Feedback API call provides access to transmission acknowledgement notifications for a sender-receiver communication and mode switch acknowledgements
for mode managers. The API can be either non-blocking or blocking depending on
software-component configuration. Alternatively a runnable entity can be activated by
RTA-RTE when the transmission status or mode switch acknowledgement is available in
which case no API is created.
The Rte_Feedback API takes no parameters other than the instance handle since the
return value is used to indicate either the success or failure of the API call and the
feedback status.
RTE API Reference
221
RTA-RTE V6.2.0
Reference Manual
6.9.2
Return Values
RTE_E_NO_DATA (non-blocking API only) – No data (feedback information) was available and no other error occurred when the feedback read was attempted.
RTE_E_TIMEOUT (blocking API only) – No data (feedback information) was available
within the configured timeout and no other error occurred when the feedback
read was attempted.
RTE_E_TRANSMIT_ACK – A “transmission acknowledgement” or “mode switch acknowledgement” has been received. This return value indicates no error was
detected during execution of the API call.
6.9.3
Notes
Transmission acknowledgement is enabled for a provided DataElementPrototype by the
presence of an AcknowledgementRequest with type transmission.
Mode switch acknowledgement is enabled for a provided ModeDeclarationGroupPrototype by the presence of an ModeSwitchAck with a specified timeout.
A blocking API is created for a provided DataElementPrototype (ModeDeclarationGroupPrototype) if acknowledgement is enabled and a WaitPoint references a DataSendCompletedEvent (ModeSwitchedAckEvent) that in turn references the DataElementPrototype (ModeSwitchPoint).
A non-blocking API is created for a provided DataElementPrototype (ModeDeclarationGroupPrototype) if acknowledgement is enabled and a DataSendPoint (ModeSwitchPoint) references the DataElementPrototype but no DataSendCompletedEvent (ModeSwitchedAckEvent) references the DataElementPrototype (ModeSwitchPoint).
When a DataSendCompletedEvent (ModeSwitchedAckEvent) that references a DataElementPrototype (ModeSwitchPoint) and a runnable entity then RTA-RTE will trigger
the specified runnable when the acknowledgment is processed and will provide a nonblocking API call to read the acknowledgement state. It is not valid to combine activating a runnable entity with a blocking API call.
6.9.4
Example
Consider a provided port, pa, containing a data element val of type SInt16 that is specified using the SUCCESS element with a feedback method of wake_up_of_wait_point.
The following calls can then be made:
Rte_Send_pa_val(self, 23);
if (Rte_Feedback_pa_val(self) == RTE_E_TRANSMIT_ACK)
{
/* Transmit okay */
}
6.10
Rte_IInvalidate
222
RTE API Reference
RTA-RTE V6.2.0
Reference Manual
void
Rte_IInvalidate_<re>_<p>_<d>([IN Rte_Instance <inst>))
Where <re> is the runnable entity name, <p> is the port name and <d> the data element
within the sender-receiver interface categorizing the port.
6.10.1
Description
Mark the data as “invalid”. The transmission of the invalid value will occur after the
runnable entity <re> has terminated.
6.10.2
Return Values
None.
6.10.3
Notes
An Rte_IInvalidate API is created for a provided DataElementPrototype for which a
runnable entity has DataWriteAccess where the referenced DataElementPrototype is
marked as “can invalidate”.
6.10.4
Example
Consider a provide port, pa, containing a data element val of type SInt16 which is
non-queued, accessed using implicit communication by runnable re1 and marked as
“can invalidate”. The following calls can then be made from within re1:
Rte_IInvalidate_re1_pa_val(self);
6.11
Rte_Invalidate
Std_ReturnType
Rte_Invalidate_<p>_<d>([IN Rte_Instance <inst>))
Where p is the port name and d the data element within the sender-receiver interface
that categorizes the port.
6.11.1
Description
Marks the data as “invalid” and then transmits as normal (depending on configuration the transmission of the invalid data marker may occur immediately or may be
deferred).
6.11.2
Return Values
RTE_E_OK – The data has been invalidated successfully.
RTE_E_COM_STOPPED – A communications error occurred – the data has not been
successfully passed to the communication service.
RTE API Reference
223
RTA-RTE V6.2.0
Reference Manual
6.11.3
Notes
An Rte_Invalidate API is created for a DataSendPoint that references a non-queued
DataElementPrototype that is marked as “can invalidate”.
AUTOSAR restricts invalidation to integer types.
6.11.4
Example
Consider a provide port, pa, containing a data element val of type SInt16 which is
non-queued and marked as “can invalidate”. The following call can then be made:
Rte_Invalidate_pa_val(self);
6.12
Rte_IRead
<data type>
Rte_IRead_<re>_<p>_<d>([IN Rte_Instance <inst>))
Where <re> is the runnable entity name, <p> is the port name and <d> the data element
within the sender-receiver interface categorizing the port.
6.12.1
Description
Perform an implicit read on a sender-receiver communication using non-queued semantics. The API is always implemented as a macro rather than a generated function.
The data item accessed by the Rte_IRead API is guaranteed not to change during execution of runnable <re>.
The Rte_IRead API returns the read data using the API return type.
6.12.2
Return Values
Dependent on data value.
6.12.3
Notes
An Rte_IRead API is created for a required DataElementPrototype if the runnable entity
has DataReadAccess that refers to the DataElementPrototype.
Implicit communication supports primitive data types and complex types including
records.
6.12.4
Example
Consider a required port, ra, containing a data element val of type SInt16 accessed
from runnable entity re1. The following call can then be made:
SInt16 a;
a = Rte_IRead_re1_ra_val(self);
224
RTE API Reference
RTA-RTE V6.2.0
Reference Manual
6.13
Rte_IWrite
void
Rte_IWrite_<re>_<p>_<d>([IN Rte_Instance <inst>]
IN <type> <data>)
Where re is the runnable entity name, p is the port name and d the data element within
the sender-receiver interface categorizing the port.
6.13.1
Description
Perform an implicit write on a sender-receiver communication using “data” semantics.
The API is always implemented as a macro rather than a generated function.
The data item written by the Rte_IWrite API is only made visible to other components
after the runnable re has terminated.
6.13.2
Return Values
None.
6.13.3
Notes
An Rte_IWrite API is created for a required DataElementPrototype if the runnable entity has DataWriteAccess that refers to the DataElementPrototype.
Implicit communication supports primitive data types and records. When a complex
data type is used the second parameter is a pointer to the data.
6.13.4
Example
Consider a provided port, pa, containing a data element val of type SInt16 accessed
from runnable entity re1. The following call can then be made:
Rte_IWrite_re1_pa_val(self, 23);
6.14
Rte_IWriteRef
<type>*
Rte_IWriteRef_<re>_<p>_<d>([IN Rte_Instance])
Where re is the runnable entity name, p is the port name and d the data element within
the sender-receiver interface categorizing the port.
6.14.1
Description
Access a reference to the RTE manager buffer used for implicit writes on a senderreceiver communication using “data” semantics. The API is always implemented as a
macro rather than a generated function. The reference can be used to directly update
members/elements of complex types.
RTE API Reference
225
RTA-RTE V6.2.0
Reference Manual
The data item written by the Rte_IWriteRef API is only made visible to other components after the runnable re has terminated.
6.14.2
Return Values
Rte_IWriteRef returns a reference to the corresponding data element. Therefore the
return type of Rte_IWriteRef is dependent on the data element type.
6.14.3
Notes
An Rte_IWriteRef API shall be created for a provided DataElementPrototype if the
RunnableEntity has DataWriteAccess that refers to the DataElementPrototype. Thus
the API will be generated for both primitive and complex data types though it is most
useful with complex types to update single fields/elements of the type.
The Rte_IWriteRef API can be used as an l-value within an assignment.
6.14.4
Example
Consider a required port, ra, containing a data element val of structure type RecType
accessed from runnable entity re1. The following calls can then be made:
RecType* r = Rte_IWriteRef_re1_ra_val(self);
r->field = 23;
6.15
Rte_IrvIRead
<data type>
Rte_IrvIRead_<re>_<name>([IN Rte_Instance <inst>])
Where <re> is the runnable entity name and <name> the inter-runnable variable name.
6.15.1
Description
Provide read access to an inter-runnable variable with an IMPLICIT communication approach. Where data consistency is required, access to the inter-runnable variable by a
runnable entity is redirected to a copy created by RTA-RTE.
The Rte_IrvIRead API returns the value of the inter-runnable variable using the API
return type.
6.15.2
Return Values
Dependent on data value. Note that inter-runnable variables do not support complex
types or strings.
6.15.3
Notes
The Rte_IrvIRead API mapping is implemented as a macro written to the component’s
application header file by the RTE generator. If support for multiple instances is disabled within the software-component’s internal behavior the macro is implemented as
a direct access of the component data structure.
226
RTE API Reference
RTA-RTE V6.2.0
Reference Manual
An Rte_IrvIRead API is created for each “ReadVariable” with an IMPLICIT communication approach that is referenced by a runnable entity. The generated RTE includes appropriate data copies to ensure that the access to the inter-runnable variable is atomic.
The concurrency control applied to inter-runnable variable access ensures that the read
is atomic – it does not, however, ensure that a read-modify-write cycle is protected. If
such protection is required then a per-instance memory section and an exclusive area
should be used instead.
Inter-runnable variables support primitive data types (excluding strings).
6.15.4
Example
Consider an inter-runnable variable irv1 (with type SInt16 and IMPLICIT access) referenced by runnable entity re1. The following API call can then be made:
SInt16 a;
a = Rte_IrvIRead_re1_irvl(self);
6.16
Rte_IrvIWrite
void
Rte_IrvIWrite_<re>_<name>([IN Rte_Instance <inst>],
IN <data>)
Where <re> is the runnable entity name and <name> the inter-runnable variable name.
6.16.1
Description
Provide write access to an inter-runnable variable. Where data consistency is required
access to the inter-runnable variable by a runnable entity is redirected to a copy created by RTA-RTE
6.16.2
Return Values
The return value of Rte_IrvIWrite API is always void – the call is implemented as a
macro and cannot fail.
6.16.3
Notes
The Rte_IrvIWrite API mapping is implemented as a macro written to the component’s application header file by the RTE generator. If support for multiple instances is
disabled within the software-component’s internal behavior the macro is implemented
as a direct access of the component data structure.
An Rte_IrvIWrite API is created for each “WrittenVariable” with an IMPLICIT communication approach that is referenced by a runnable entity. The generated RTE includes
appropriate concurrency control to ensure that the write of the inter-runnable variable
is atomic.
The concurrency control applied to inter-runnable variable access ensures that the
RTE API Reference
227
RTA-RTE V6.2.0
Reference Manual
write is atomic – it does not, however, ensure that a read-modify-write cycle is protected. If such protection is required then a per-instance memory section and an exclusive area should be used instead.
Inter-runnable variables support primitive data types (excluding strings).
6.16.4
Example
Consider an inter-runnable variable irv1 (with type SInt16 and IMPLICIT access) referenced using ‘written’ semantics by runnable entity re1. The following API call can then
be made:
SInt16 a;
Rte_IrvIWrite_re1_irvl(self, a);
6.17
Rte_IrvRead
<data type>
Rte_IrvRead_<re>_<name>([IN Rte_Instance <inst>])
Where <re> is the runnable entity name and <name> the inter-runnable variable name.
6.17.1
Description
Provide read access to an inter-runnable variable with an EXPLICIT communication
approach. The access to the inter-runnable variable is guaranteed to be atomic.
The Rte_IrvRead API returns the value of the inter-runnable variable using the API
return type.
6.17.2
Return Values
Dependent on data value. Note that inter-runnable variables do not support complex
types or strings.
6.17.3
Notes
The Rte_IrvRead API mapping is implemented as a macro written to the component’s
application header file by the RTE generator. If support for multiple instances is disabled
the macro is implemented as a direct invocation of the function generated within the
RTE.
An Rte_IrvRead API is created for each “ReadVariable” with an EXPLICIT communication approach that is referenced by a runnable entity. The generated RTE includes
appropriate concurrency control to ensure that the access to the inter-runnable variable
is atomic.
The concurrency control applied to inter-runnable variable access ensures that the read
is atomic – it does not, however, ensure that a read-modify-write cycle is protected. If
such protection is required then a per-instance memory section and an exclusive area
should be used instead.
228
RTE API Reference
RTA-RTE V6.2.0
Reference Manual
Inter-runnable variables support primitive data types (excluding strings).
6.17.4
Example
Consider an inter-runnable variable irv1 (with type SInt16) referenced by runnable
entity re1. The following API calls can then be made:
SInt16 a;
a = Rte_IrvRead_re1_irvl(self);
6.18
Rte_IrvWrite
void
Rte_IrvWrite_<re>_<name>([IN Rte_Instance <inst>],
IN <data>)
Where <re> is the runnable entity name and <name> the inter-runnable variable name.
6.18.1
Description
Provide write access to an inter-runnable variable with an EXPLICIT communication approach. The access to the inter-runnable variable is guaranteed to be atomic.
6.18.2
Return Values
The return value of Rte_IrvWrite API is always void – the call is implemented as a
macro and therefore cannot fail.
6.18.3
Notes
The Rte_IrvWrite API mapping is implemented as a macro written to the component’s
application header file by the RTE generator. If support for multiple instances is disabled
the macro is implemented as a direct invocation of the function generated within the
RTE.
An Rte_IrvWrite API is created for each “WrittenVariable” with an EXPLICIT communication approach that is referenced by a runnable entity. The generated RTE includes
appropriate concurrency control to ensure that the write of the inter-runnable variable
is atomic.
The concurrency control applied to inter-runnable variable access ensures that the
write is atomic – it does not, however, ensure that a read-modify-write cycle is protected. If such protection is required then a per-instance memory section and an exclusive area should be used instead.
Inter-runnable variables support primitive data types (excluding strings).
6.18.4
Example
Consider an inter-runnable variable irv1 (with type SInt16) referenced using ‘written’
semantics by runnable entity re1. The following API calls can then be made:
RTE API Reference
229
RTA-RTE V6.2.0
Reference Manual
SInt16 a;
Rte_IrvWrite_re1_irvl(self, a);
6.19
Rte_IStatus
Std_ReturnType
Rte_IStatus_<re>_<p>_<d>([IN Rte_Instance <inst>])
Where <re> is the runnable entity name, <p> is the port name and <d> the data element
within the sender-receiver interface categorizing the port.
6.19.1
Description
Provide read access to the error state of an implicitly accessed datum.
6.19.2
Return Values
RTE_E_OK – No error detected.
RTE_E_COM_STOPPED – A communications error occurred – the data has not been
successfully passed to the communication service.
6.19.3
Notes
An Rte_IStatus API is created for each datum with implicit read access and a runnable
entity triggered by a DataReceiveErrorEvent.
6.19.4
Example
Consider a SW-C with port prototype pa categorized by an interface containing datum
value (with type SInt16) where the datum is accessed using ‘read’ access by re1 and
a DataReceiveErrorEvent is configured to activate re1. The following API calls can then
be made:
Std_ReturnType r;
r = Rte_IStatus_re1_pa_value(self);
6.20
Rte_IsUpdated
Std_ReturnType
Rte_IsUpdated_<p>_<vdp>([IN Rte_Instance <inst>])
Where <p> is the port name and <vdp> the VariableDataPrototype within the senderreceiver interface categorizing the port.
6.20.1
Description
Indicate whether the VariableDataPrototype has been updated or not.
230
RTE API Reference
RTA-RTE V6.2.0
Reference Manual
6.20.2
Return Values
TRUE – DataElement updated since last read.
FALSE – DataElement not updated since last read.
6.21
Rte_MainFunction
void
Rte_MainFunction(void)
6.21.1
Description
Rte_MainFunction is a vendor-specific API used by RTA-RTE to implement Minimum
Start Intervals (Section 4.10.10).
If Minimum Start Intervals are used, then Rte_MainFunction must be called periodically to notify RTA-RTE of the passing of time. By default, RTA-RTE expects the function
to be called every 10 milliseconds, but you can choose your own period by using the
--period command-line option. Note however that all minimum start intervals in the
system must be an integer multiple of this period.
6.21.2
Return Values
None.
6.21.3
Notes
The Rte_MainFunction API is declared in Rte_Main.h.
The Rte_MainFunction API is RTA-RTE specific.
Rte_MainFunction can always be called, but when there are no Minumum
Start Intervals present, it has no effect.
You can use the preprocessor
_
_
symbol RTE MAINFUNCTION REQUIRED to check whether it is necessary to call
Rte_MainFunction.
The configured period is made available with the pre-processor symbol RTE_MAINFUNCTION_PERIOD_NS that expands to the period in nanoseconds.
For convenience the symbols RTE_MAINFUNCTION_PERIOD_US and
RTE_MAINFUNCTION_PERIOD_MS are provided at microsecond and millisecond precision respectively. These expand to integer values when the period is an integer
multiple of one microsecond or one millisecond respectively, otherwise they expand to
floating point values.
6.21.4
Example
Assume ISR isr1 is triggered every millisecond. Rte_MainFunction can be invoked at
the correct rate using the following code:
ISR(isr1)
RTE API Reference
231
RTA-RTE V6.2.0
Reference Manual
{
#ifdef RTE_MAINFUNCTION_REQUIRED
# if ( ( RTE_MAINFUNCTION_PERIOD_NS % 1000000UL ) != 0 )
# error "Configured Rte_MainFunction invocation period is not a
multiple of 1ms"
# endif /* ( ( RTE_MAINFUNCTION_PERIOD_NS % 1000000UL ) != 0 ) */
static uint16 count = RTE_MAINFUNCTION_PERIOD_MS;
#endif /* RTE_MAINFUNCTION_REQUIRED */
#ifdef RTE_MAINFUNCTION_REQUIRED
if ( 0 == --count )
{
count = RTE_MAINFUNCTION_PERIOD_MS;
Rte_MainFunction();
}
#endif /* RTE_MAINFUNCTION_REQUIRED */
...
}
6.22
Rte_Mode
Rte_ModeType_<m>
Rte_Mode_<port>_<item>([IN Rte_Instance <inst>])
Where <port> is the port name, <item> the mode declaration group prototype name
within the sender-receiver interface categorizing the port and <m> the name of the
referenced mode declaration group.
6.22.1
Description
Read the current mode for a “mode graph”.
6.22.2
Return Values
The return value from the Rte_Mode API indicates the current mode. The name of the
returned data type is derived from the name of the mode declaration group.
6.22.3
Notes
The Rte_Mode API is created when a ModeDeclarationGroupPrototype is declared within
a provided or required interface.
The Rte_Mode API is always a non-blocking API.
The Rte_Mode API generated for an unconnected port always returns the mode declaration group’s initial mode. No mode switch event other than ENTRY to the initial mode
(i.e. within Rte_Start) will ever be triggered.
232
RTE API Reference
RTA-RTE V6.2.0
Reference Manual
6.22.4
Example
Consider a required port, ra, containing a mode declaration group prototype mode that
references mode declaration group mg1. The following API call can then be made:
Rte_ModeType_mg1 m = Rte_Mode_ra_mode(self);
6.23
Rte_Ports
Rte_PortHandle_<i>_<P/R>
Rte_Ports_<i>_<P/R>([IN Rte_Instance <inst>])
Where <i> is the interface name and <P/R> dependent on whether the ports ‘provide’
or ‘require’ the interface.
6.23.1
Description
The Rte_Ports API provides access to the base of an array created for each interface
(and ‘provide’ or ‘require’ usage) of a software-component. The Rte_Ports API supports iteration through similarly typed ports when combined with the Rte_NPorts API.
6.23.2
Return Values
The Rte_Ports API returns a port handle corresponding to the appropriate interface
and ‘provide’ or ‘require’ usage. Port handles are declared in the application header
file.
6.23.3
Notes
One Rte_Ports API is created for each interface (inc. ‘provide’ or ‘require’ usage) used
within a software-component. Thus a software-component includes port specifications
that both require and provide the same interface will result in two Rte_Ports APIs being
generated.
RTA-RTE includes an explicit array within the component data structure to
store individual port data structures. This is safe with regards port iteration
and consistent with the AUTOSAR SWS requirements but is inconsistent with
the example given in the AUTOSAR SWS.
6.23.4
Example
Consider a software component with two required ports, ra and rb, both typed by
interface i2. An Rte_Ports API consistent with the following signature would then be
created:
Rte_PortHandle_i2_R Rte_Ports_i2_R(Rte_Instance);
6.24
Rte_NPorts
uint8
Rte_NPorts_<i>_<P/R>([IN Rte_Instance <inst>])
RTE API Reference
233
RTA-RTE V6.2.0
Reference Manual
Where xmltagi is the interface name and <P/R> dependent on whether the ports ‘provide’ or ‘require’ the interface.
6.24.1
Description
The Rte_NPorts API provides access to the size of the array created for each interface (and ‘provide’ or ‘require’ usage) of a software-component. The Rte_NPorts API
supports iteration through similarly typed ports when combined with the Rte_Ports
API.
6.24.2
Return Values
The Rte_NPorts API returns a uint8 corresponding to the number of ports that use the
same interface and ‘provide’ or ‘require’ usage.
6.24.3
Notes
One Rte_NPorts API is created for each interface (inc. ‘provide’ or ‘require’ usage
) used within a software-component for which the indirect API is created. Thus a
software-component includes port specifications that both require and provide the
same interface will result in two Rte_NPorts APIs being generated.
6.24.4
Example
Consider a software component with two required ports, ra and rb, both typed by
interface i2. An Rte_Ports API consistent with the following signature would then be
created:
uint8 Rte_NPorts_i2_R(Rte_Instance);
The Rte_NPorts_i2_R API would return two since there are two require ports typed by
interface i2.
The Rte_NPorts API can be combined with the Rte_Ports API to support iteration over
similarly typed ports, for example:
uint8 count = Rte_NPorts_i2_R(self);
Rte_PortHandle_i2_R base = Rte_Ports_i2_R(self);
for ( p = 0; p < count; p++ )
{
base[p]->Send_a(49);
}
6.25
Rte_Port
Rte_PortHandle_<i>_<P/R>
Rte_Port_<port>([IN Rte_Instance <inst>])
234
RTE API Reference
RTA-RTE V6.2.0
Reference Manual
Where <port> is the port name, <i> the interface name and <P/R> dependent on
whether the ports ‘provide’ or ‘require’ the interface.
6.25.1
Description
The Rte_Port API provides access to port handle for a specified port of a softwarecomponent. The API allows a software-component to extract a sub-group of ports typed
by the same interface in order to iterate over this sub-group.
6.25.2
Return Values
The Rte_Ports API returns a port handle corresponding to the appropriate interface
and ‘provide’ or ‘require’ usage. Port handles are declared in the application header
file.
6.25.3
Notes
One Rte_Port API is created for each port declared within a software-component.
6.25.4
Example
Consider a software component with two required ports, ra and rb, both typed by interface i2. Two Rte_Port APIs would be created consistent with the following signature:
Rte_PortHandle_i2_R Rte_Ports_ra(Rte_Instance);
Rte_PortHandle_i2_R Rte_Ports_rb(Rte_Instance);
6.26
Rte_Pim
<type>*
Rte_Pim_<name>([IN Rte_Instance <inst>])
Where <name> is the short-name name of the per-instance memory section to access.
6.26.1
Description
The Rte_Pim API provides access to a named per-instance memory (PIM) section defined in the software component type. The function returns a pointer to a data memory
section that can be used directly, without any need for type casting, by the softwarecomponent.
6.26.2
Return Values
A pointer to an instance of the type defined for the per-instance memory section.
The data type of the per-instance memory section is defined in the software component’s application header file and therefore the actual type for each generated Rte_Pim
call will vary.
RTE API Reference
235
RTA-RTE V6.2.0
Reference Manual
6.26.3
Notes
An Rte_Pim API is created for each defined PerInstanceMemorySection within a
software-component.
RTA-RTE instantiates the per-instance memory section once for each component instance. When multiple instances of a component are possible the macro is mapped to
access the state within the specified instance. When only a single instance is known
to exist, the indirection through the instance handle may be elided and thus impose no
run-time penalty on access to static memory sections.
6.26.4
Example
The following example illustrates the use of Rte_Pim. The following declaration of a
per-instance memory section:
<PER-INSTANCE-MEMORY>
<SHORT-NAME>val</SHORT-NAME>
<TYPE>dataType</TYPE>
<TYPE-DEFINITION>
struct { uint8 var1; ... }
</TYPE-DEFINITION>
</PER-INSTANCE-MEMORY>
Results in the creation by RTA-RTE of an instance of dataType that can be accessed
through the Rte_Pim_val API call:
FUNC(void, RTE_APPL_CODE)
tt1(Rte_Instance self)
{
dataType* ds = Rte_Pim_val(self);
ds->var1 = 23;
// ...
}
6.27
Rte_Read
Std_ReturnType
Rte_Read_<port>_<item>([IN Rte_Instance <inst>,]
OUT <data>)
Where <port> is the port name and <item> the data element within the sender-receiver
interface that categorizes the port.
6.27.1
Description
Perform an explicit read on a sender-receiver communication using “data” semantics.
The Rte_Read API includes exactly one OUT parameter to pass back the received data
– the data will be passed by reference for all data types.
236
RTE API Reference
RTA-RTE V6.2.0
Reference Manual
6.27.2
Return Values
RTE_E_OK – The data has been read successfully.
RTE_E_TIMEOUT (blocking API only) – No data was received within the configured
timeout.
RTE_E_NO_DATA (non-blocking API only) – No data was available for reading but no
other error occurred when the read was attempted. This return value is not considered an error.
6.27.3
Notes
The Rte_Read call is created when a DataElementPrototype has an isQueued declaration of “false”.
A non-blocking API is created if a DataReceivePoint references a required DataElementPrototype with ‘data’ semantics
Blocking Rte_Read API calls are not permitted in the AUTOSAR RTE specification.
When a DataReceiveEvent that references a DataElementPrototype and a runnable entity then RTA-RTE will trigger the specified runnable when a datum is received and will
provide a non-blocking API call to read the received datum. It is not valid to combine
activating a runnable entity with a blocking API call.
6.27.4
Example
Consider a required port, ra, containing a data element val of type SInt16 with an
isQueued declaration of “false”. The following calls can then be made:
SInt16 a;
Std_ReturnType e = Rte_Read_ra_val(self, &a);
if (e == RTE_E_OK)
{
/* Read okay */
}
6.27.5
Related APIs
See also Rte_DRead, Rte_Receive.
6.28
Rte_DRead
<type>
Rte_DRead_<port>_<item>([IN Rte_Instance <inst>])
RTE API Reference
237
RTA-RTE V6.2.0
Reference Manual
Where <port> is the port name and <item> the data element within the sender-receiver
interface that categorizes the port.
6.28.1
Description
Perform an explicit read on a sender-receiver communication using “data” semantics.
The Rte_Read API includes exactly one OUT parameter to pass back the received data
– the data will be passed by reference for all data types.
6.28.2
Return Values
RTE_E_OK – The data has been read successfully.
RTE_E_TIMEOUT (blocking API only) – No data was received within the configured
timeout.
RTE_E_NO_DATA (non-blocking API only) – No data was available for reading but no
other error occurred when the read was attempted. This return value is not considered an error.
6.28.3
Notes
The Rte_Read call is created when a DataElementPrototype has an isQueued declaration of “false”.
A non-blocking API is created if a DataReceivePoint references a required DataElementPrototype with ‘data’ semantics
Blocking Rte_Read API calls are not permitted in the AUTOSAR RTE specification.
When a DataReceiveEvent that references a DataElementPrototype and a runnable entity then RTA-RTE will trigger the specified runnable when a datum is received and will
provide a non-blocking API call to read the received datum. It is not valid to combine
activating a runnable entity with a blocking API call.
6.28.4
Example
Consider a required port, ra, containing a data element val of type SInt16 with an
isQueued declaration of “false”. The following calls can then be made:
SInt16 a;
Std_ReturnType e = Rte_Read_ra_val(self, &a);
if (e == RTE_E_OK)
{
/* Read okay */
}
6.29
Rte_Receive
238
RTE API Reference
RTA-RTE V6.2.0
Reference Manual
Std_ReturnType
Rte_Receive_<port>_<item>([IN Rte_Instance <inst>,]
OUT <data>)
Where <port> is the port name and <item> the data element within the sender-receiver
interface that categorizes the port.
6.29.1
Description
Perform an explicit read on a sender-receiver communication using “event” semantics.
The Rte_Receive API includes exactly one OUT parameter to pass back the received
data – the data will be passed by reference for all data types.
6.29.2
Return Values
RTE_E_OK – The data has been read successfully.
RTE_E_TIMEOUT (blocking API only) – No data was received within the configured
timeout.
RTE_E_NO_DATA (non-blocking API only) – No data was available for reading but no
other error occurred when the read was attempted. This return value is not considered an error.
6.29.3
Notes
The Rte_Receive call is created when a DataElementPrototype is “QUEUED”.
A non-blocking API is created if a DataReceivePoint references a required DataElementPrototype with ‘QUEUED’ semantics
A blocking API is created if a DataReceivePoint references a required DataElementPrototype with ‘QUEUED’ semantics and a WaitPoint references a DataReceiveEvent
that references the same DataElementPrototype.
When a DataReceiveEvent that references a DataElementPrototype and a runnable entity then RTA-RTE will trigger the specified runnable when an event is received and will
provide a non-blocking API call to read the received event. It is not valid to combine
activating a runnable entity with a blocking API call.
6.29.4
Example
Consider a required port, ra, containing a data element val of type SInt16 with the
isQueued attribute set to “true”. The following calls can then be made:
SInt16 a;
Std_ReturnType e = Rte_Receive_ra_val(self, &a);
if (e == RTE_E_OK)
{
/* Receive okay */
RTE API Reference
239
RTA-RTE V6.2.0
Reference Manual
}
6.30
Rte_Result
Std_ReturnType
Rte_Result_<port>_<op>([IN Rte_Instance <inst>,]
[OUT <out_param_1>], ...,
[OUT <out_param_n>])
Where <port> is the port name and <op> the operation within the client-server interface that categorizes the port.
6.30.1
Description
The Rte_Result API is used to poll for the result and the error state of an asynchronous
client-server communication. The call can be either blocking or non-blocking.
The Rte_Result API includes zero or more OUT parameters to pass back results from
the server. All OUT parameters are passed by reference for all data types
6.30.2
Return Values
The return value is used to indicate errors from either the Rte_Result call itself or
communication errors detected before the API call was made.
RTE_E_OK – The call completed successfully.
RTE_E_TIMEOUT (blocking call only) – No reply was received within the configured
timeout.
RTE_E_NO_DATA (non-blocking call only) – No data was available for reading but no
other error occurred when the read was attempted. This return value is not considered an error.
6.30.3
Notes
A non-blocking API is created for an AsynchronousServerCallReturnsEvent that references a required OperationPrototype and no WaitPoint references the AsynchronousServerCallReturnsEvent.
A blocking API is created for an AsynchronousServerCallReturnsEvent that references a
required OperationPrototype and a WaitPoint references the AsynchronousServerCallReturnsEvent.
When an AsynchronousServerCallReturnsEvent that references an OperationPrototype
and a runnable entity then RTA-RTE will trigger the specified runnable when the server
result is received and will provide a non-blocking API call to read the received result. It
is not valid to combine activating a runnable entity with a blocking API call.
240
RTE API Reference
RTA-RTE V6.2.0
Reference Manual
6.30.4
Example
Consider a required port, pa, containing an operation op1 which is invoked asynchronously with the result being collected using a blocking API call. The following calls
can then be made:
SInt16 a;
Std_ReturnType e;
Rte_Call_pa_op1(self, 1);
e = Rte_Result_pa_op1(self, &a)
if (e == RTE_E_OK)
{
/* Result received okay */
}
6.31
Rte_Send
Std_ReturnType
Rte_Send_<port>_<item>([IN Rte_Instance <inst>,]
IN <data>)
Where <port> is the port name and <item> the data element within the sender-receiver
interface that categorizes the port.
6.31.1
Description
Initiates a sender-receiver communication using queued semantics.
The Rte_Send API includes exactly one IN parameter for data – this will be passed by
value for primitive data types and by reference for all other types.
6.31.2
Return Values
RTE_E_OK – The data has been passed to communication service successfully. Depending on bus load the data may or may not have been transmitted.
RTE_E_COM_STOPPED – A communications error occurred – the data has not been
successfully passed to the communication service.
6.31.3
Notes
An Rte_Send API call is created when a DataSendPoint is specified for a provided DataElementPrototype for which the isQueued attribute is set to “true”.
The API returns when the signal has been passed to the communication service for
transmission. Depending on the communication server the transmission may or may
not have been acknowledged by the receiver.
RTE API Reference
241
RTA-RTE V6.2.0
Reference Manual
If a sender port has multiple receivers connected, the generated Rte_Send API will try
to write to all receivers independently. This ensures that. for example, the overflow
in one component’s queue does not prevent the transmission of this message to other
components.
6.31.4
Example
Consider a provided port, ra, containing a data element val of type SInt16 with the
isQueued attribute set to “true”. The following call can then be made:
Std_ReturnType e = Rte_Send_ra_val(self, 23);
if (e == RTE_E_OK)
{
/* Transmission okay */
}
6.32
Rte_Start
Std_ReturnType
Rte_Start( void )
6.32.1
Description
This function is invoked (typically by the ECU state manager or possibly by user code)
to start the RTE.
The Rte_Start API is responsible for starting the execution of periodic runnables and
for initiating execution of runnables trigger by ModeSwitchEvents for ENTRY to the initial mode.
When the Rte_Start API completes the RTE is initialized and the RTE’s response to
inter-ECU communication is enabled.
6.32.2
Return Values
RTE_E_OK – No error detected.
RTE_E_LIMIT – Unable to start periodic runnable entities.
6.32.3
Notes
The Rte_Start invokes OS APIs to start the execution of timing triggered runnables.
6.33
Rte_Stop
Std_ReturnType
Rte_Stop( void )
242
RTE API Reference
RTA-RTE V6.2.0
Reference Manual
6.33.1
Description
This function is invoked (typically by the ECU state manager or possibly by user code)
to stop the RTE.
The Rte_Stop API is responsible for stopping further execution of periodic runnables.
Note that runnables already running will not be terminated.
When the Rte_Stop API completes no further RTE initiated activity will take place and
the RTE’s response to inter-ECU communication is disabled.
6.33.2
Return Values
RTE_E_OK – No error detected.
RTE_E_LIMIT – Error when trying to stop periodic runnable entities.
6.33.3
Notes
The Rte_Stop API invokes OS APIs to halt execution of timing triggered runnables. The
selected API depends on the chosen OS plug-in.
6.34
Rte_Switch
Std_ReturnType
Rte_Switch_<port>_<item>([IN Rte_Instance <inst>,]
IN <data>)
Where <port> is the port name and <item> the mode declaration group prototype
name within the sender-receiver interface categorizing the port.
6.34.1
Description
Initiates a mode switch transition within a “mode graph”.
The Rte_Switch API includes exactly one IN parameter for data passed by value. The
IN parameter indicates the required ‘next’ mode.
The Rte_Switch API initiates the mode switch if the mode graph is not currently involved in a transition. Otherwise the request is queued.
The Rte_Switch API supports synchronous and asynchronous mode switches. The latter method is selected when explicitly enabled by all mode users.
6.34.2
Return Values
RTE_E_OK – The mode switch request has been queued successfully.
RTE_E_LIMIT – The mode switch request has been discarded due to a full request
queue.
RTE API Reference
243
RTA-RTE V6.2.0
Reference Manual
6.34.3
Notes
The Rte_Switch call is generated for each mode declaration group prototype within
the categorizing interface for a provided port where at least one runnable entity has a
ModeSwitchPoint declared for the mode declaration group prototype.
If a provided port has multiple receivers connected, the mode switch will apply to all
receivers.
The Rte_Switch API generated for an unconnected port discards the mode switch request and returns RTE_E_OK. No mode switch will occur as a result of the API’s invocation.
6.34.4
Example
Consider a provided port, ra, containing a mode declaration group prototype mode.
Furthermore, assume that the referenced mode declaration group defines the mode
RUN. The following Rte_Switch call can then be made:
Std_ReturnType e;
e = Rte_Switch_ra_mode(self, RTE_MODE_RUN);
if (e != RTE_E_OK)
{
/* Mode switch request failed */
}
6.35
Rte_Tick_Timeouts
void
Rte_Tick_Timeouts(void)
6.35.1
Description
Rte_Tick_Timeouts ticks the Rte_Tout_Counter and sets any necessary OS events
when alarms expire.
To prevent missed runnable activations and event settings it is important not
to tick Rte_Tout_Counter directly but to call Rte_Tick_Timeouts instead.
6.35.2
Return Values
None.
6.35.3
Notes
Rte_Tick_Timeouts is needed in when generated RTE has timeouts present in the system and is generated for AUTOSAR OS or OSEK OS.
The Rte_Tick_Timeouts API is a vendor-specific mechanism created in order to ensure compatibility with the restrictions placed by AUTOSAR OS and
OSEK OS on the use of OS API calls in Alarm Callbacks.
244
RTE API Reference
RTA-RTE V6.2.0
Reference Manual
Rte_Tick_Timeouts should be called at the interval (in microseconds) defined by RTARTE in RTE_ALARM_COUNTER_TICK_INTERVAL_US.
Although the prototype is always present in Rte.h, the function itself is only generated if timeouts are present in the system.
If no timeouts are present the
RTE_ALARM_COUNTER_TICK_INTERVAL_US preprocessor symbol is undefined.
It is recommended to use conditional compilation (see the example below) to cause the call to Rte_Tick_Timeouts call only to be included when
RTE_ALARM_COUNTER_TICK_INTERVAL_US is defined
6.35.4
Example
This example demonstrates the recommended way of calling Rte_Tick_Timeouts from
within an ISR body.
uint8 count = USECONDS_TO_TICKS ( RTE_ALARM_COUNTER_TICK_INTERVAL_US
);
...
#ifdef RTE_ALARM_COUNTER_TICK_INTERVAL_US
if ( 0 == --count )
{
count = USECONDS_TO_TICKS ( RTE_ALARM_COUNTER_TICK_INTERVAL_US );
Rte_Tick_Timeouts();
}
#endif /* RTE_ALARM_COUNTER_TICK_INTERVAL_US */
6.36
Rte_Trigger
void
Rte_Trigger_<p>_<itp>(void)
Where <p> is the port name and <itp> is the name of the InternalTriggeringPoint.
6.36.1
Description
Trigger the execution for all runnables whose ExternalTriggerOccurredEvent is associated with the trigger.
6.37
Rte_IrTrigger
void
Rte_IrTrigger_<re>_<itp>(void)
RTE API Reference
245
RTA-RTE V6.2.0
Reference Manual
Where <re> is the runnable entity name and <itp> is the name of the InternalTriggeringPoint.
6.37.1
Description
Trigger the execution for all runnables whose InternalTriggerOccurredEvent is associated with the trigger.
6.38
Rte_Write
Std_ReturnType
Rte_Write_<port>_<data>([IN Rte_Instance <inst>,]
IN <data>)
Where <port> is the port name and <item> the data element within the sender-receiver
interface that categorizes the port.
6.38.1
Description
Rte_Write initiates sender-receiver communication using “UNQUEUED” semantics.
The call includes exactly one IN parameter for data – this will be passed by value for
primitive data types and by reference for all other types.
6.38.2
Return Values
RTE_E_OK – The data has been passed to communication service successfully. Depending on bus load the data may or may not have been transmitted.
RTE_E_COM_STOPPED – A communications error occurred – the data has not been
successfully passed to the communication service.
RTE_E_SIGNAL_DISCARDED – The signal was discarded (failed to pass an outgoing
filter) without being transmitted. This return is not considered to be an error.
Value-based filters are not implemented in RTA-RTE
RTE_E_LIMIT – An internal limit (e.g. queue length) has been exceeded.
6.38.3
Notes
An Rte_Write API call is created when a DataSendPoint is specified for a provided DataElementPrototype with ‘data’ semantics. The Rte_Write API call is generated when the
isQueued attribute for the data element prototype is set to “false”.
The API returns when the signal has been passed to the communication service for
transmission. Depending on the communication server the transmission may or may
not have been acknowledged by the receiver.
246
RTE API Reference
RTA-RTE V6.2.0
Reference Manual
If a sender port has multiple receivers connected, the Rte_Write API must try to write
to all receivers independently. This ensures that overflow in one component’s queue
does not prevent the transmission of this message to other components.
6.38.4
Example
Consider a provided port, ra, containing a data element val of type SInt16 with the
isQueued attribute set to “false”. The following calls can then be made:
Std_ReturnType e = Rte_Write_ra_val(self, 23);
if (e == RTE_E_OK)
{
/* Transmission okay */
}
RTE API Reference
247
RTA-RTE V6.2.0
Reference Manual
7
RTE Runnable API Reference
A software-component implementation defines functions that provide the entry points
for runnable entities. The call name and parameters of the entry point function vary
depending on the event that triggers the runnable entity.
7.1
Supported RTE Events
The following classes of RTE event are supported by RTA-RTE;
Asynchronous Server Call Returns Event – a runnable entity activated when the
result of an asynchronous invocation of a client-server operation is available. The
function providing the runnable entity’s entry point has void return type and
takes no parameters (other than an instance handle if the software-component
supports multiple instantiation).
Data Receive Error Event – a runnable entity invoked by RTA-RTE when a data receive error occurs. The function providing the runnable entity’s entry point has
void return type and takes no parameters (other than an instance handle if the
software-component supports multiple instantiation).
Data Received Event – a runnable entity invoked by RTA-RTE when a signal is received. The function providing the runnable entity’s entry point has void return
type and takes no parameters (other than an instance handle if the softwarecomponent supports multiple instantiation).
Data Send Completed Event – a runnable entity invoked by RTA-RTE when a transmission completes. The function providing the runnable entity’s entry point has
void return type and takes no parameters (other than an instance handle if the
software-component supports multiple instantiation).
Mode Switch Event – a runnable entity invoked by RTA-RTE either on entry to, or on
exit from, a mode. The function providing the runnable entity’s entry point has
void return type and takes no parameters (other than an instance handle if the
software-component supports multiple instantiation).
Uniquely, RTA-RTE supports a “fast init” activation method for Mode Switch Events
that bypasses the normal AUTOSAR activation method for events that are triggered only once at system startup. See Section 7.3 below for further details.
Mode Switched Ack Event – a runnable entity invoked by RTA-RTE when a mode
transition is complete. The function providing the runnable entity’s entry point
has void return type and takes no parameters (other than an instance handle if
the software-component supports multiple instantiation).
Operation Invoked Event – a runnable entity that implements an operation in a
client-server interface. The runnable entity’s entry function can take zero or more
parameters in addition to the instance handle depending on the input configuration and has a return type of void or Std_ReturnType depending on whether or
not the server returns an application error..
248
RTE Runnable API Reference
RTA-RTE V6.2.0
Reference Manual
Timing Event – Runnable entity triggered by time. The function providing the
runnable entity’s entry point has void return type and takes no parameters (other
than an instance handle if the software-component supports multiple instantiation).
The name for an runnable entity’s entry point function contained within the <SYMBOL>
element in the software-component description. The application header file includes a
prototype for the required entry point function.
All runnable entities, whatever the event that triggers the runnable, must
be declared in the input XML.
7.2
Signature
Apart from runnables triggered by an OperationInvoked event all functions implementing a runnable entity have the same signature:
FUNC(void, RTE_APPL_CODE)
<name>([IN Rte_Instance <instance>])
Where <name> is the runnable entity’s <SYMBOL> and <instance> is a user-defined
name for the instance handle. The instance handle is omitted if the softwarecomponent is declared as not supporting multiple instantiation.
The function implementing
RTE_APPL_CODE.
the
runnable
should
be
declared
as
The function implementing an OperationInvoked event must declare a formal parameter list matching the operation arguments. The formal parameter list can include
port-defined arguments or operation arguments:
( FUNC(void, RTE_APPL_CODE)
| FUNC(Std_ReturnType, RTE_APPL_CODE )
<name>([IN Rte_Instance <instance>],
[IN <portDefArg_1>, ...
IN <portDefArg_n>]
[IN|INOUT|OUT <param_1>, ...
IN|INOUT|OUT <param_n>] )
Where <name> is the runnable entity’s <SYMBOL> and <instance> is a user-defined
name for the instance handle. The instance handle is omitted if the softwarecomponent is declared as not supporting multiple instantiation.
For an OperationInvoked event, the return type must be FUNC(void, RTE_APPL_CODE)
except where the interface declares one or more application errors in which case the
type must be FUNC(Std_ReturnType, RTE_APPL_CODE).
All instances of a component are independent however the runnable entities of each
instance share the same code. As a consequence multiple threads of control can be
RTE Runnable API Reference
249
RTA-RTE V6.2.0
Reference Manual
concurrently executing the same runnable entity and therefore either the runnable entity must be reentrant or multiple instances must be explicitly forbidden.
7.3
SWC Initialization
AUTOSAR modes can be used to execute code when the RTE is started, e.g. to initialise
internal data structures etc. Each mode declaration group describes an initial mode –
to activate a runnable when the system is started created by a <MODE-SWITCH-EVENT>
for entry to the initial mode.
A runnable entity within a software-component can be started when the RTE is started
by declaring a <MODE-SWITCH-EVENT> for entry to an initial mode.
However for a runnable that only runs once at system start the infrastructure code
created by RTA-RTE to support the AUTOSAR mode mechanism is superfluous. Therefore RTA-RTE provides the FastInit mechanism to optimize activation for specified ModeSwitchEvents by mapping them to specified FastInit tasks as simple function calls. The
use of a FastInit task both simplifies the activation code necessary for the runnable associated with the event as well as removing the normal infrastructure code created by
RTA-RTE to support the AUTOSAR mode mechanism.
The FastInit mechanism must be enabled for each applicable ModeSwitchEvent using
the --fast-init command-line option.
An event that is specified as FastInit will not be activated by RTA-RTE during
a user-triggered mode switch. Instead the FastInit task must be activated
by user code at the appriopriate time.
250
RTE Runnable API Reference
RTA-RTE V6.2.0
Reference Manual
8
VFB Tracing
When VFB tracing is enabled within the RTE module configuration (see Section 4.19.2)
RTA-RTE inserts VFB Trace event hook calls into generated code. However VFB tracing must also be globally enabled within the user-supplied configuration file and the
specific required hooks enabled for tracing to have an effect.
8.1
Enabling VFB Tracing
During RTE generation phase, the RTE generator creates a header file, Rte_Hook.h,
that defines the signature and usage of VFB Trace event hook calls. The generated
Rte_Hook.h file #includes the user-supplied configuration file Rte_Cfg.h that:
• Globally enables or disables all VFB Trace events.
• Enables individual VFB Trace events.
8.1.1
Global Enable
The following definition, within Rte_Cfg.h, globally disables all VFB Trace events:
#define RTE_VFB_TRACE (0)
And the following definition globally enables VFB Trace events:
#define RTE_VFB_TRACE (1)
When VFB Tracing is globally disabled no VFB Trace hooks will be made (irrespective of
the configuration of individual trace events) and the VFB Trace hooks embedded within
the generated RTE by RTA-RTE will have zero run-time impact.
When VFB Tracing is globally enabled individual trace events are enabled within
Rte_Cfg.h by defining the name of the trace event hook function. For example, the
“OS Task Dispatch” trace event is enabled by the following definition in Rte_Cfg.h:
#define Rte_Task_Dispatch
Whereas the “API Start” trace event for software-component type swc, port pa, data
item d2 and API call Rte_Write would be enabled by the following definition in
Rte_Cfg.h:
#define Rte_WriteHook_swc_pa_d2_Start
8.2
Trace Events
8.2.1
RTE API Start
RTE API Start is invoked by the RTE when an API call is made by a software component.
void
Rte_<api>Hook_<c>_<ap>_Start([IN Rte_Instance <inst>,]
<params>)
VFB Tracing
251
RTA-RTE V6.2.0
Reference Manual
Where <api> is the API root name (Write, Call, Feedback, etc.), <c> the softwarecomponent type name and <ap> the access point (combination of port name and data
item name/operation name separated by an underscore).
The parameters of the RTE API Start trace event hook are the same as the corresponding RTE API. The Instance handle is elided when a software-component is singly instantiated.
8.2.2
RTE API Return
RTE API Return is invoked by the RTE just before an API call returns control to a component.
void
Rte_<api>Hook_<c>_<ap>_Return([IN Rte_Instance <inst>,] <params>)
Where <api> is the API root name (Write, Call, Feedback, etc.), <swc> the softwarecomponent type name and <ap> the access point (combination of port name and data
item name/operation name separated by an underscore).
The parameters of the RTE API Return trace event hook are the same as the corresponding RTE API. The Instance handle is elided when a software-component is singly
instantiated.
8.2.3
Signal Transmission
A trace event indicating a transmission request of an Inter-ECU signal or signal group
by the RTE. Invoked by the RTE just before Com_SendSignal or Com_SendSignalGroup
is invoked.
void
Rte_ComHook_<signal>_SigTx(<data>)
Where <signal> is the system signal name and <data> is a pointer to the signal data
to be transmitted.
For a system signal, the parameter of the signal transmission trace event hook is the
data to be transmitted.
8.2.4
Signal Reception
A trace event indicating an attempt to read Inter-ECU signal by the RTE. Invoked by the
RTE after successful return from Com_ReceiveSignal.
void
Rte_ComHook_<signal>_SigRx(<data>)
Where <signal> is the system signal name and <data> is a pointer to the signal data
received.
The parameter of the signal reception trace event hook is the data received.
252
VFB Tracing
RTA-RTE V6.2.0
Reference Manual
8.2.5
COM Notification
A trace event indicating the start of a COM notification. Invoked by the generated RTE
code on entry to the COM call-back.
void
Rte_ComHook_<signal>(void)
Where <signal> is the system signal name.
8.2.6
OS Task Activation
A trace event invoked by the RTE immediately before activating the specified task.
void
Rte_Task_Activate(TaskType t)
Where <t> is the handle of the task to be activated.
8.2.7
OS Task Dispatch
A trace event invoked by the RTE immediately on dispatch of the specified generated
task (provided it contains runnable entities).
void
Rte_Task_Dispatch(TaskType t)
Where <t> is tha handle of the task to be activated.
8.2.8
OS Task Set Event
A trace event invoked immediately before generated RTE code attempts to set an OS
Event.
void
Rte_Task_SetEvent(TaskType task, EventType ev)
Where <t> is tha handle of the task to be activated and <ev> the Os event to be set.
8.2.9
OS Task Wait Event
A trace event invoked immediately before generated RTE code attempts to wait for an
OS Event.
void
Rte_Task_WaitEvent(TaskType task, EventType ev)
Where <t> is tha handle of the task to be activated and <ev> the Os event(s).
8.2.10
OS Task Wait Event Return
A trace event invoked immediately before generated RTE code returns from waiting for
an OS Event.
VFB Tracing
253
RTA-RTE V6.2.0
Reference Manual
void
Rte_Task_WaitEventRet(TaskType task, EventType ev)
Where <t> is tha handle of the task to be activated and <ev> the set Os event(s).
8.2.11
Runnable Entity Invocation
Event invoked by the RTE just before execution of runnable entry starts via its entry
point. This trace event occurs after any copies of data elements are made to support
the Rte_IRead API Call.
void
Rte_Runnable_<swc>_<reName>_Start(IN Rte_Instance <inst>)
Where <swc> is the software-component type name and <reName> the runnable entity
name.
8.2.12
Runnable Entity Termination
Event invoked by the RTE immediately execution returns to RTE code from a runnable
entity. This trace event occurs before write-back of data elements are made to support
the Rte_IWrite API Call.
void
Rte_Runnable_<c>_<reName>_Return([IN Rte_Instance <inst>)]
Where <swc> is the software-component type name and <reName> the runnable entity
name.
8.3
Trace Event Implementation
The implementation of a trace event hook function is entirely within the user domain –
all that is necessary to supply when linking is a function implementation that conforms
to one of the trace event signatures defined above.
For example, the task dispatch event might be implemented as follows:
#include <Os.h>
#include Rte_Hook.h’’
void Rte_Task_Dispatch(TaskType t)
{
if ( t == taskA )
{
/* Log task A dispatch */
}
}
254
VFB Tracing
RTA-RTE V6.2.0
Reference Manual
8.4
Optimization
Enabling VFB tracing, either via the ECU configuration description or the command-line
option, disables certain optimizations within the generated RTE:
• Intra-task (and inter-task to a ‘pure’ server) client-server communication is not optimized to a direct function call.
VFB Tracing
255
RTA-RTE V6.2.0
Reference Manual
9
Memory Mapping and Compiler Abstraction
9.1
Memory Mapping
RTA-RTE-generated code and data allocations are placed into memory sections using the AUTOSAR memory mapping scheme. The name of the memory section
is derived from the SwAddrMethod referenced by the AutosarDataPrototype or
ExecutableEntity.
For
illustration,
consider
a
VariableDataProtype
that
references
a
SwAddrMethod named group1 which has memoryAllocationKeywordPolicy of
swAddrMethodShortName. RTA-RTE uses the following mapping when instantiating the
receive buffer:
#define RTE_START_group1
#include "Rte_MemMap.h"
...
#define RTE_STOP_group1
#include "Rte_MemMap.h"
This mechanism allows RTE code to remain target-independent. The compiler-specific
behavior (e.g. emitting #pragmas, redefining memory section macros) is contained in
Rte_MemMap.h which you must supply.
The memory mapping scheme was implemented according to AUTOSAR
4.0.3, which is compatible with 4.2.1, but uses the 4.2.1 filename
Rte_MemMap.h. If your project conforms with AUTOSAR 4.0.3 and your
memory mapping file is named MemMap.h then you can supply an additional Rte_MemMap.h file containing only the preprocessor directive
#include "MemMap.h".
9.1.1
Getting Started
RTA-RTE can generate a skeleton Rte_MemMap.h file. Use the --samples option to do
this.
The supplied memory configuration in Rte_MemMap.h and Compiler_Cfg.h
files is intended as an example only and should be verified as suitable for
the chosen target development hardware configuration before use.
9.1.2
Generating Rte_MemMap.h
Since a project may require very many Memory Allocation Keywords, it will be desirable to generate the Rte_MemMap.h automatically. This can be done by reading the
Rte_BSWMD.arxml report emitted by RTA-RTE during the generation step, as follows:
The format of a Memory Allocation Keyword created by RTA-RTE is ‹prefix›_‹action›_‹sectionName› where:
prefix is always RTE. Rte_BSWMD.arxml does not contain a ModulePrefix so a
memmap generator tool does not need to look for one.
256
Memory Mapping and Compiler Abstraction
RTA-RTE V6.2.0
Reference Manual
action is START_SEC or STOP_SEC. START_SEC is used to set up the compiler to use a
particular memory section and STOP_SEC is used to tear down before setting up
another memory section.
sectionName is the symbol of the corresponding MemorySection, which is present in
Rte_BSWMD.arxml and can be found by the fact that it references a SwAddrMethod
in common with the data or code allocation in question.
For interest, RTA-RTE always sets the MemorySection.shortName the same as the
MemorySection.symbol, and this relates to the SwAddrMethod.shortName according to
the SwAddrMethod.memoryAllocationKeywordPolicy.
If
memoryAllocationKeywordPolicy
is
addrMethodShortName
then
MemorySection.shortName, MemorySection.symbol and SwAddrMethod.shortName
are the same.
If the memoryAllocationKeywordPolicy is addrMethodShortNameAndAlignment
then the MemorySection.shortName and MemorySection.symbol are the
SwAddrMethod.shortName plus an ‹alignmentSuffix›, one of the following:
• _BOOLEAN
• _8
• _16
• _32
• _64 (if --have-64bit-int-types is enabled)
• _UNSPECIFIED
RTA-RTE uses the Memory Allocation Sequence both for data allocations
and for external declarations. Some compilers issue warnings for this; others issue warnings if the declarations differ from the allocations. Option
--deviate-memmap-decls can tune this behavior.
9.1.3
Default AUTOSAR MemorySections
When data or code implied by the input model has no associated SwAddrMethod in the
input model, RTA-RTE uses a default SwAddrMethod according to the AUTOSAR Memory Mapping specification. These SwAddrMethods are created internally when RTA-RTE
starts up, and any SwAddrMethods on the input using the same shortName as any of
these must be compatible with the internal definition or RTA-RTE will log a warning.
These “implied” memory sections are:
• VAR_CLEARED for variables not initialized, or initialized to zero.
• VAR_INIT for variables with initial values.
Memory Mapping and Compiler Abstraction
257
RTA-RTE V6.2.0
Reference Manual
• CONST for constants.
• CALIB for calibration parameters.
• CODE for code.
9.1.4
ApplicationSwComponentType-specific MemMap.h
RTA-RTE expects a ‹shortName›_MemMap.h for each ApplicationSwComponentType
used in the ECU configuration. This file is for the entry points of the RunnableEntitys in
the ASW Component. This feature does not apply to entry points in BSW compoments.
9.1.5
Variation: Implicit Communication
When option --implicit-allocation-method is enabled, the task-specific
implicit buffer structures are placed according to SwAddrMethods named
VAR_IMPLICITSR_‹TASKNAME› where ‹TASKNAME› is the OsTask.shortName converted to upper case.
9.1.6
Variation: Task Bodies
When option --deviate-task-sections is enabled, task bodies are not placed in section CODE, but TASKBODY_‹taskName› where ‹taskName› is the OsTask.shortName without case conversion.
9.2
Compiler Abstraction
The AUTOSAR compiler abstraction enables objects located with the memory mapping
to be referenced. This is achieved through the definition of object classes within the
file Compiler_Cfg.h.
9.2.1
Defined Classes
RTA-RTE defines the following object classes:
RTE_CONST – Memory class used to access objects declared within the generated RTE
using RTE_*_SEC_CONST_*.
RTE_DATA – Memory class used to access objects declared within the generated RTE
using RTE_*_SEC_DATA_*.
RTE_CODE – Memory class used to access (i.e. create function pointers) to objects declared within the generated RTE using RTE_*_SEC_CODE.
RTE_APPL_CONST – Memory class uses to access constant data within an application,
typically via a pointer passed into an RTE API.
RTE_APPL_DATA – Memory class uses to access data within an application, typically via
a pointer passed into an RTE API.
RTE_APPL_CODE – Memory class used to access (i.e. create function pointers) to objects
declared within the application code space.
258
Memory Mapping and Compiler Abstraction
RTA-RTE V6.2.0
Reference Manual
RTE_OS_CDATA – Memory class used to access constant data within the operating system.
RTE_LIBCODE – Memory class used to declare and access RTE library functions.
No object class exists, or is required by the generated RTE, for access to objects created
with the TASKBODY memory class.
9.2.2
Customization
RTA-RTE permits customization of the compiler abstraction through an XML Memory
Section Description File. See RTA-RTE Toolchain Integration Guide for more details.
Memory Mapping and Compiler Abstraction
259
RTA-RTE V6.2.0
Reference Manual
10
External Dependencies
RTA-RTE references symbols that are in the scope of external libraries and other AUTOSAR modules, in particular:
• C library (optional).
• OS Configuration.
• COM APIs (optional, only required when inter-ECU communication is present).
• OS APIs.
• Calibration parameters.
10.1
C Library
By default, RTA-RTE is independent of the C library and uses the RTE library define
function Rte_memcpy to copy memory.
Alternatively, RTA-RTE can be configured to use the C library’s memcpy function if the
symbol RTE_LIBC_MEMCPY is defined when compiling both the RTE library and generated code.
The standard memcpy function from the C Library may be preferred for certain targets,
for example, to reduce code size by sharing memcpy with other modules that already
use the C Library or to improve the efficiency of compiled code by using a version of
the memcpy function “built-in” to the compiler that produces optimal inline assembler.
10.2
OS Configuration
The RTE and OS for a particular ECU have a complex relationship in that the OS configuration partly influences the RTE and the RTE configuration partly influences the OS.
At the minimum the names and priorities of the Os tasks that will execute the runnable
entities and the Os tasks and Os ISRs that will execute the schedulable entities are necessary as an input to RTE generation. This information defines the concurrency model
of the system and defines the set of tasks whose bodies are part of the generated
RTE. The RTE will however require additional Os objects, for example to schedule those
tasks, to provide for the execution of only the activated runnables during particular task
executions and to serialize access to application / BSW module code and internal state,
depending on the configuration of the involved software components and BSW modules. Furthermore the configuration may require particular settings for the Os tasks,
for example an Os task that executes at least one runnable entity with a WaitPoint may
need to be an extended task.
RTA-RTE optionally generates an OS configuration file (see Section 2.3) containing definitions for all OS objects used by the generated RTE and the necessary configuration
for those Os tasks that have runnable entities or schedulable entities mapped to them.
If this file is not used during OS configuration then the following OS objects will be
required to be created:
260
External Dependencies
RTA-RTE V6.2.0
Reference Manual
10.2.1
Resources
RTE_RESOURCE* OsResources to support the RTE API.
RTA-RTE uses an RTE-specific OsResource with an OsResourceProperty of
STANDARD to serialize access to internal RTE state.
In the single-core case, this resource shall be called RTE_RESOURCE.
In the multi-core case, tasks in the master core (i.e. with logical core ID 0) shall
use RTE_RESOURCE and tasks on all cores with logical core <n> greater than 0
shall use RTE_RESOURCE_CORE_<n>.
Therefore, a system with four cores requires the following resources:
• RTE_RESOURCE
• RTE_RESOURCE_CORE1
• RTE_RESOURCE_CORE2
• RTE_RESOURCE_CORE3
Any task containing code that uses the RTE API needs to be declared as
locking RTE_RESOURCE, or the RTE_RESOURCE_CORE_<n> for the core
on which the task executes. Additionally, any task or ISR in whose
context BSW modules may call back into RTE-generated code for notifications (e.g. for notification of COM reception) must also be declared
as locking this resource. Failure to do so may result in runtime errors.
RTE_RESOURCE is created in the OsNeeds report if not present in the input. (At the
time of writing, OsNeeds is not supported in the multicore case.)
Rte_EA_<i>_<n>/Rte_EI_<i>_<n> An AUTOSAR standard / internal resource created
to ensure serialized access to exclusive area <n> within runnable entities from
SW-C instance <i>.
The name of the SW-C prototype, <i>, is an internal name created by the RTA-RTE
RTE generator. The mapping between user visible component prototype name
and internal name is included in Rte_Const.h.
RTA-RTE will not create a resource if an existing resource is specified within the
ECUC file (see Section 4.19.2).
RTA-RTE will optimize away the use of an OS resource if either all accessing
runnable entities are mapped to the same task or all accessing runnable entities
are mapped to tasks with the same priority. If the use of the resource is optimized
away by RTA-RTE then no OS object need be created.
10.2.2
Schedule Tables
Rte_ScheduleTable An AUTOSAR OS Schedule table used within the generated RTE for
execution of tasks containing runnable entities triggered by Timing RTE events.
External Dependencies
261
RTA-RTE V6.2.0
Reference Manual
10.2.3
Counters
The RTA-RTE RTE generator uses counters for driving alarms required by generated
code.
Rte_Tick_Counter An AUTOSAR OS Counter used by application code to control execution of Rte_ScheduleTable or generated periodic alarms.
The required counter tick rate depends on periods of Timing RTE events and is
indicated by an RTA-RTE information message and by a definition within the generated file Rte_Const.h.
Rte_TOut_Counter An AUTOSAR OS Counter used by application code to control execution of sporadic alarms, e.g. for timeouts.
The required counter tick rate is fixed at 1ms and is defined within the generated
file Rte_Const.h.
To prevent missed runnable activations and event settings it is important
not to tick Rte_Tout_Counter directly but instead to call the generated RTE
API Rte_Tick_Timeouts instead, see Section 6.35.
10.2.4
Alarms
The RTA-RTE RTE generator uses alarms for handling timeouts, for scheduling sporadic
activities and, optionally, for scheduling periodic activities.
Rte_<task>_timeoutAlarm An AUTOSAR OS Alarm used within the generated RTE to
indicate a timeout for a runnable mapped to OS task <task>.
Rte_Alarm_<i>_<p>_<d> Sporadic alarm created to indicate a timeout for SWC instance <i>, port <p> and datum/mode group <d>.
rte_alAct_<p>_<o> or rte_alAct_<ev> Periodic alarm defined for a TimingEvent.
If the ECUC associates OS event <ev> with the timing event instance has a defined
OS event then the _<ev> form of the name is used. Otherwise the alarm name
includes the timing event period <p> and offset <o>.
To prevemt overlong names, this release of RTA-RTE assigns internal names
to alarms rather than constructing names according to the scheme above.
Consult the generated OS configuration for details.
10.2.5
Events
The RTA-RTE RTE generator uses OS events both for internal task scheduling and for
handling the wake-up-of-waitpoint receive mode.
Rte_Activity An AUTOSAR OS event used within the generated RTE for Wake-up-ofwaitpoint handling to indicate that an RTE Event has occurred.
262
External Dependencies
RTA-RTE V6.2.0
Reference Manual
The OS event must be referenced by any task that contains runnable entities that
can wait.
The event mask must be ’1’ and must be the same for all tasks using the event.
Rte_Timeout An AUTOSAR OS event used within the generated RTE for Wake-up-ofwaitpoint handling to indicate a timeout has occurred while waiting for an RTE
event.
The event must be referenced by any task that contains runnable entities that
can wait and have a timeout specified.
The event mask must be ’2’ and must be the same for all tasks using the event.
When required, the RTA-RTE RTE generator uses OS events to perform internal task
scheduling. If the OS event name is not specified in the ECU description, the RTE generator constructs OS event names as follows:
Rte_Ev_<period>_<offset> An AUTOSAR OS event created to indicate a Timing RTE
event has occurred when multiple runnable entities are mapped to a task. The
<period> and <offset> are the period and offset of the Timing RTE event. All
runnable entities within a task with the same period share the same event.
This OS event is only created when no user-supplied OS event is referenced within
the RTE Event’s runnable entity map and runnable entities triggered by Timing
RTE events and other RTE events are mapped to the same task.
Rte_Ev_<i>_<p>_<d> An AUTOSAR OS event created to trigger runnable started by an
event associated with SW-C prototype <i>, port <p> and datum <d>.
The name of the SW-C prototype, <i>, is the internal name not the name declared
within the composition since the latter is not necessarily unique.
This OS event is only created when no user-supplied OS event is referenced within
the RTE Event’s runnable entity map and runnable entities triggered by Timing
RTE events and other RTE events are mapped to the same task.
The names of OS events used for internal task scheduling can also be specified in the ECU description. If specified the ECU description name will override the default name defined in the table above.
10.3
AUTOSAR COM
AUTOSAR COM module is a mandatory requirement of RTA-RTE when inter-ECU communication is used (RTA-RTE implements intra-ECU communication without using COM).
10.3.1
Initialization
COM must be started before the RTE. Therefore the RTE is not responsible for initializing
COM and Rte_Start does not invoke the Com_Init API.
External Dependencies
263
RTA-RTE V6.2.0
Reference Manual
RTA-RTE uses periodic transmission when “cyclic” or “n-times” communication is used.
Therefore the Com_StartPeriodic API should be used to initialize periodic activity
within COM in addition to invoking Com_Init.
10.3.2
Data Types
RTA-RTE uses AUTOSAR data types when communicating with COM. The definitions of
these data types are defined in Rte_Type.h and this file can be used to make the type
definitions visible to a COM implementation.
10.3.3
Transmission and Invalidation
RTA-RTE uses signals or signal groups for transmission and therefore the following COM
APIs are used:
Com_SendSignal( Com_MessageIdentifier,
Com_ApplicationDataRef )
Com_UpdateShadowSignal( Com_MessageIdentifier,
Com_ApplicationDataRef )
Com_InvalidateSignal( Com_MessageIdentifier )
Com_InvalidateShadowSignal( Com_MessageIdentifier )
Com_SendSignalGroup( Com_SignalGroupIdType )
10.3.4
Reception
RTA-RTE uses signals or signal groups for reception and therefore the following COM
APIs are used:
Com_ReceiveSignal( Com_MessageIdentifier,
Com_ApplicationDataRef )
Com_ReceiveShadowSignal( Com_MessageIdentifier,
Com_ApplicationDataRef )
Com_ReceiveSignalGroup( Com_SignalGroupIdType )
10.3.5
Call-backs
RTA-RTE uses COM call-backs to receive notification when communication related
events have occurred; for example data reception. The call-backs are created in Rte.c
but must be declared in the COM configuration attached to the appropriate signal.
Callbacks are used for the following events:
Rte_COMCbk_<signal> – Data reception.
Rte_COMCbkTOut_<signal> – Data reception timeout.
Rte_COMCbkInv_<signal> – Invalid data reception.
Rte_COMCbkTAck_<signal> – Acknowledgement of data transmission.
264
External Dependencies
RTA-RTE V6.2.0
Reference Manual
10.4
Operating System
An Operating System module is a mandatory requirement of RTA-RTE.
10.4.1
Concurrency Control
Internally RTA-RTE uses an AUTOSAR OS resource for concurrency control. In a multicore system this become an OS resource for each AUTOSAR core, for core-local concurrency control. Generated code can either use an OS resource or interrupt blocking
depending on the configuration. The following OS APIs are therefore used to control
concurrency:
GetResource( ResourceType )
ReleaseResource( ResourceType )
SuspendOSInterrupts( void )
ResumeOSInterrupts( void )
All OS tasks or ISRs that invoke RTE API functions must be declared as locking the
standard resource RTE_RESOURCE in a single-core system. This is done automatically in
the generated OS configuration for all generated tasks.
For a multi-core system, tasks and ISRs on the master core (with core ID zero) must be
declared as locking RTE_RESOURCE and tasks and ISRs on slave cores (core ID greater
than zero) must be delcared as locking the standard resources RTE_RESOURCE_CORE<n>
where <n> is the core ID of the slave core.
10.4.2
Alarms
RTA-RTE uses alarms for periodic and sporadic events. The following OS APIs are used
to manipulate alarms:
SetRelAlarm( AlarmType, TickType, TickType )
CancelAlarm( AlarmType )
10.4.3
Events
RTA-RTE uses OS events to implement certain RTE events, for example, APIs requiring
a WaitPoint and for RTA-RTE code within generated task bodies. The following APIs are
used to manipulate OS events:
SetEvent( TaskType, EventType )
WaitEvent( EventType )
GetEvent( TaskType, EventType* )
ClearEvent( EventType )
10.4.4
Tasks
RTA-RTE uses tasks to execute runnable entities. The following OS APIs are used to
manipulate tasks:
ActivateTask( TaskType )
ChainTask( TaskType )
External Dependencies
265
RTA-RTE V6.2.0
Reference Manual
TerminateTask( void )
GetTaskID( void )
10.4.5
Schedule Tables
RTA-RTE uses an AUTOSAR schedule table to execute tasks containing runnable entities
triggered by Timing RTE events. The following OS APIs are used to manipulate the
schedule table:
// OS R1.0:
StartScheduleTable( ScheduleTableType, TickType )
// OS R3.0:
StartScheduleTableRel( ScheduleTableType, TickType )
StopScheduleTable( ScheduleTableType )
10.5
Calibration
RTA-RTE supports the following calibration methods:
• “None” – no software support is generated (RTE APIs for accessing calibration parameters access the allocated data directly). The RTE generator expects calibration
parameters to be updated externally, e.g. by direct memory access from calibration hardware.
• “Single-pointered” – RTA-RTE generates a reference table (in RAM) that locates calibration data. The calibration values returned by individual generated RTE APIs can
be modified by changing pointers in the reference table to point to alternate values
in either RAM or ROM.
• “Double-pointered” – RTA-RTE generates a reference table (in ROM) and a reference base (in RAM) that points to the table. The calibration values returned by all
generated RTE APIs can be modified by changing the base pointer to reference a
different table.
• “Init-RAM” – RTA-RTE generates a RAM copy of all parameters and an initializing
ROM block. Generated RTE APIs access the RAM copy.
• “Single-pointered2” – RTA-RTE generates individual reference pointers (in RAM) that
locate calibration data. The calibration values returned by individual generated RTE
APIs can be modified by changing those reference pointers. This is a non-AUTOSAR
extension.
For the pointered methods, all calibration parameters within an SW-C that reference the same swAddrMethod are grouped within a calibration parameter
group. Grouping can also optionally be enabled for method “None” using the
--deviate-group-calibration-none command-line option.
If no <SW-ADDR-METHOD> is referenced the name nullSWAddr is used.
266
External Dependencies
RTA-RTE V6.2.0
Reference Manual
To be able to import or instantiate the required calibration parameter groups, RTA-RTE
must define both the type and the instance names.
For the “Init-RAM” method the calibration parameters are also grouped in the same way
but the groups are further collected into a structure for allocation of the RAM and ROM
blocks. This allows a single copy operation to initialize all RAM blocks. To be able to
instantiate the RAM and ROM blocks RTA-RTE must define the type and instance names
of the RAM and ROM block structures, the type names for calibration parameter groups
and the order and names of the elements in the RAM/ROM block structures.
10.5.1
Type Name
Non-grouped Parameters
When using the calibration method “None” RTA-RTE does not normally create calibration parameter groups and hence instantiated parameters simply uses the data type of
the calibration parameter. When the --deviate-group-calibration-none commandline option is enabled the group naming follows the same rules as for the pointered
methods.
Grouped Parameters
A calibration parameter group is implemented as a C structure. The type is declared
within Rte_Type.h and the type name is:
Rte_CGT<loc>_<swci>_<swAddr>
Where:
• <loc> is an RTA-RTE symbol depending on the location of the calibration parameter
definitions:
• c – calibration parameters within a CalPrmComponentType.
• u – calibration parameters within an unconnected RPort within an ApplicationComponentType.
• s – shared calibration parameters within a SWC Type.
• i – per-instance parameters within a SWC Type.
• <swci> is as follows:
• For calibration parameters within a CalPrmComponentType, calibration parameters within unconnected RPorts of an ApplicationComponentType and perinstance calibration parameters declared within a SWC type, this field is the
SWC instance internal name1 .
• For shared calibration parameters declared within an SWC type, this field is the
SWC type name.
1
The RTE configuration constants file includes support for associating component prototypes and the
RTE’s internal name. See Sections 10.5.5 and ??.
External Dependencies
267
RTA-RTE V6.2.0
Reference Manual
• <swAddr> is the swAddrMethod name, except for calibration parameters within an
unconnected RPort when it is the port name followed by the swAddrMethod name,
separated by an underscore.
The type of each group is also described, using AUTOSAR XML, in the McSupportData file created by RTA-RTE.
Note that the type name of the data structure is based on the internal RTARTE SWCI identifier and a data type is declared for each instance of the SWC
type because different SwAddrMethods may be applied to different instances using
FlatInstanceDescriptors and hence the groups may be different for each instance.
10.5.2
Instance Name
Non-grouped Parameters
When using the calibration method “none” the instance name is taken from the flatmap
instance if one is available for the calibration parameter instance. The name of the
flatmap instance must be globally unique.
If no flatmap instance is available then RTA-RTE uses the name of the calibration parameter. RTA-RTE will raise an error if it detects two calibration parameters are declared
with the same name. To avoid this error either use a flatmap instance to rename one
ot both of the parameters or enable generation of calibration parameter groups using
the appropriate command-line option.
Grouped Parameters
RTA-RTE instantiates calibration parameter groups as required.
The name of allocated/imported instance of the calibration parameter group is:
Rte_CG<loc>_<swci>_<swAddr>
Where:
• <loc> is an RTA-RTE symbol depending on the location of the calibration parameter
definitions, as for the calibration parameter group type:
• c – calibration parameters within a CalPrmComponentType.
• u – calibration parameters within an unconnected RPort within an ApplicationComponentType.
• s – shared calibration parameters within a SWC Type.
• i – per-instance parameters within a SWC Type.
• <swci> is as follows:
• For calibration parameters within a CalPrmComponentType, calibration parameters within unconnected RPorts of an ApplicationComponentType and per268
External Dependencies
RTA-RTE V6.2.0
Reference Manual
instance calibration parameters declared within a SWC type, this field is the
SWC instance internal name2 .
• For shared calibration parameters declared within an SWC type, this field is the
SWC type name.
• <swAddr> is the swAddrMethod name, except for calibration parameters within an
unconnected RPort when it is the port name followed by the swAddrMethod name,
separated by an underscore.
10.5.3
Init-RAM Structures
When using calibration method “Init-RAM” RTA-RTE creates a single combined RAM
block containing space for all the calibration parameters and a single combined ROM
block with the initializer for every calibration parameter. Both blocks use the following
structure type:
Rte_CalprmInitRAMType
The RAM block is instantiated as a variable of that type called:
Rte_CalprmInitRAM
and the ROM block is instantiated as a constant of that type called:
Rte_CalprmInitROM
This scheme allows a single copy operation to perform the initialization of all parameters at once.
Within the blocks the parameters are grouped together following the same scheme
as for the pointered calibration methods, namely by SW-C and swAddrMethod. Each
element of the Rte_CalprmInitRAMType structure is itself a structure, for a calibration
parameter group. The names of the calibration parameter group structure types follow
the same rules as for the pointered calibration methods, as set out in section 10.5.1.
The element names are:
CG<loc>_<swci>_<swAddr>
Where:
• <loc> is an RTA-RTE symbol depending on the location of the calibration parameter
definitions:
• c – calibration parameters within a CalPrmComponentType.
• u – calibration parameters within an unconnected RPort within an ApplicationComponentType.
2
The RTE configuration constants file includes support for associating component prototypes and the
RTE’s internal name. See Sections 10.5.5 and ??.
External Dependencies
269
RTA-RTE V6.2.0
Reference Manual
• s – shared calibration parameters within a SWC Type.
• i – per-instance parameters within a SWC Type.
• <swci> is as follows:
• For calibration parameters within a CalPrmComponentType, calibration parameters within unconnected RPorts of an ApplicationComponentType and perinstance calibration parameters declared within a SWC type, this field is the
SWC instance internal name3 .
• For shared calibration parameters declared within an SWC type, this field is the
SWC type name.
• <swAddr> is the swAddrMethod name, except for calibration parameters within an
unconnected RPort when it is the port name followed by the swAddrMethod name,
separated by an underscore.
The elements appear in the Rte_CalprmInitRAMType structure sorted by name.
10.5.4
Examples
The following examples illustrate the allocation of calibration parameters to groups and
the import of parameters by RTA-RTE.
Shared Calibration Parameters
Consider a SWC type swcA that declares shared calibration parameters A and B both of
which reference swAddrMethod Md.
Since both calibration parameters reference the same swAddrMethod and are declared
in the same SWC type they are allocated to the same calibration parameter group. The
type definition within Rte_Type.h is therefore:
typedef struct {
<type> A;
<type> B;
} Rte_CGTs_swcA_Md;
And the instance name is:
Rte_CGs_swcA_Md
For the “Init-RAM” method the type definition is unchanged but the group is instantiated
within the RAM and ROM block structures, appearing as an element of the structure as
follows:
typedef struct {
Rte_CGTs_swcA_Md CGs_swcA_Md;
} Rte_CalprmInitRAMType;
3
The RTE configuration constants file includes support for associating component prototypes and the
RTE’s internal name. See Sections 10.5.5 and ??.
270
External Dependencies
RTA-RTE V6.2.0
Reference Manual
CalPrmComponent Types
Consider a CalPrmComponent type CalData that provides a single port pd categorized
by a calibration interface that declares calibration parameters A and B both of which
reference swAddrMethod Md.
Since both calibration parameters reference the same swAddrMethod and are declared
in the same component type they are allocated to the same calibration parameter
group. However, unlike the example above the names within the generated structure
are prefixed with the port name to ensure uniqueness if the same interface categorizes
more than one port. The type definition within Rte_Type.h is therefore:
typedef struct {
<type> pd_A;
<type> pd_B;
} Rte_CGTc_<i>_Md;
and the instance names is:
Rte_CGc_<i>_Md
where <i> is the RTA-RTE internal name for the instance of the calibration component
type.
For the “Init-RAM” method the type definition is unchanged but the group is instantiated
within the RAM and ROM block structures, appearing as an element of the structure as
follows:
typedef struct {
Rte_CGTc_<i>_Md CGc_<i>_Md;
} Rte_CalprmInitRAMType;
Where <i> is the RTA-RTE internal name for the instance of the calibration component
type.
10.5.5
SWC Instance Internal Names
To ensure uniqueness when creating imported instance names for calibration parameters, RTA-RTE uses an internally allocated SWC instance name. A mapping between
a user-visible name for the component prototype and the internal name is defined in
Rte_Const.h.
For each instantiated software component prototype, Rte_Const.h includes a #define
that maps the full path to the prototype to the internal name. For example, a component prototype C1 within composition Comp1 within package pkg will have a path of
_pkg_Comp1_C1. Where nested compositions are used the path includes the name of
each level of the hierarchy.
External Dependencies
271
RTA-RTE V6.2.0
Reference Manual
10.5.6
McSupportData
RTA-RTE writes an XML description of the calibration data to the file
Rte_McSupportData.arxml. Third-party tools may use this to generate an A2L
file for use in calibration and measurement. To cause calibration parameters to be
reported to the McSupportData, each must have a FlatInstanceDescription referencing
it.
In the absence of a relevant FlatInstanceDescription, RTA-RTE emits a warning and
there will be no calibration information emitted for that parameter.
10.5.7
Special Treatment of Arrays of Curves and Maps
As an addition to AUTOSAR-specified behavior, RTA-RTE supports a shorthand way to
associate input variables with axes held in an array or structure, or axes with curves or
maps held in an array or structure.
When a calibration parameter is typed by a complex ApplicationDataType whose leaf
elements have category CURVE, MAP, COM_AXIS, or RES_AXIS, it is not necessary to
write a SwCalPrmAxisSet for each leaf element.
If an InstantiationDataDefProps references the whole complex calibration parameter, then RTA-RTE will attempt to apply its SwCalPrmAxisSet to each member of the
complex calibration parameter. Additionally, if this is the case, the SwCalPrmAxisSet
may reference, instead of the valid axis or input variable, an array or structure of the
same shape as that containing the curve, map or axis, and RTA-RTE will walk both complex types, associating the elements pairwise.
For example, an array of ten curves having a standard axis in their SwCalPrmAxisSet
might be referenced by an InstantiationDataDefProps containing a
SwCalPrmAxisSet having a swVariableRef referencing port data characterized
by a scalar type. In this case, that port data instance will be used as the input variable
for all ten curves.
Alternatively, the InstantiationDataDefProps.swVariableRef might reference an array of ten scalars, in which case RTA-RTE will treat the first scalar as the input variable
for the first curve, the seconds scalar as the input variable for the second curve, etc.
272
External Dependencies
RTA-RTE V6.2.0
Reference Manual
11
Parameters of Implementation
This chapter provides details of limits and constraints imposed by RTA-RTE.
11.1
AUTOSAR Common Published Information
RTA-RTE supports the following values for the Common Published Information (Section 4.19.2).
Parameter
R4.0
ArMajorVersion
4
ArMinorVersion
0
ArPatchVersion
1, 2 or 3
ModuleId
Not used
SwMajorVersion
1
SwMinorVersion
0
SwPatchVersion
0
VendorId
Not used
RTA-RTE will accept RTE generator version numbers up to and including the specified
version. Higher version numbers are rejected with an error.
The specification of common published information is optional. If not specified, RTA-RTE assumes that default AUTOSAR revision applies – see Section 4).
11.2
API Legitimacy
RTE API calls, other than the RTE Lifecycle API functions, are invoked by runnable entities from within task bodies generated by RTA-RTE.
The RTE Lifecycle API functions can be invoked as follows:
RTE API
Rte_Start
Task
ISR (Cat 2)
OS Startup hook
3
3
31
Rte_Stop
3
3
32
Rte_MainFunction
3
3
7
Category 1 ISRs must not invoke RTE API functions.
11.3
Tasks and Runnable Entities
When OSEK OS is used Rte_Start cannot be invoked from the StartupHook since it invokes the OSEK
API SetRelAlarm.
2
When OSEK OS is used Rte_Stop cannot be invoked from the StartupHook since it invokes the OSEK
API CancelAlarm.
1
Parameters of Implementation
273
RTA-RTE V6.2.0
Reference Manual
Parameter
Limit
Maximum number of tasks
256 (subject to support from underlying operating system).
Maximum number of runnable entities mapped to an OS task.
No limit imposed by RTA-RTE.
Maximum
TimingEvents.
No limit imposed by RTA-RTE.
However the use of non-harmonic
periods may result in large schedule tables that exceed the limits of
the underlying operating system.
number
of
Maximum number of runnable entities activated during a mode
switch.
11.4
11.5
11.6
No limit imposed by RTA-RTE.
Queued Communication
Parameter
Limit
Maximum number of entries in
a queue (for queued communication).
65535
Maximum size of each entry in a
queue (intra-ECU communication).
65535 bytes
Maximum size of each entry in a
queue (inter-ECU communication).
8 bytes
Scheduling
Parameter
Limit
Minimum supported TimingEvent
period
1 µs3
Maximum number of expiry points
10000
Modes and Mode Switches
Parameter
Limit
Maximum number of mode declarations per mode declaration
group.
32
Maximum size of a mode switch
queue.
255
3
This value is the minimum supported by RTA-RTE. The practical minimum supported timing event
period is dependent on the underlying OS implementation and will typically be significant larger.
274
Parameters of Implementation
RTA-RTE V6.2.0
Reference Manual
11.7
Inter-ECU Communication
Parameter
Limit
Maximum length of signal for a
client-server sequence counter
16 bits.
RTA-RTE always uses 16-bit types to maintain counter state since System signals do not
include the length.
Parameters of Implementation
275
RTA-RTE V6.2.0
Reference Manual
12
AUTOSAR Revision Support
This chapter provides details of optional behavior enabled using the --sws commandline option.
The --sws command-line option can be used to select the following AUTOSAR revision
specific behavior:
Behavior
Mode definitions
within application
types header or BSW
module interlink types
header files.
Type definitions and
preprocessor symbol
definitions for modes
are wrapped in an
include guard symbol.
Use of BSW module
description
short-name for entry
point prototype
definitions.
276
–sws
4.0.1
4.0.2
Notes
or
Definition uses a type-cast and parenthesis.
4.0.3
No type-cast or parenthesis are present
but instead the definition uses a U suffix
to indicate that it is an unsigned value.
4.0.1
Memory mapping and compiler abstraction macros use short-name unmodified.
4.0.2 and
above
Memory mapping and compiler abstraction macros convert short-name to
upper-case before use.
AUTOSAR Revision Support
RTA-RTE V6.2.0
Reference Manual
13
Contact, Support and Problem Reporting
For details of your local sales office as well as your local technical support team and
product hotlines, take a look at the ETAS website:
ETAS subsidiaries
www.etas.com/en/contact.php
ETAS technical support
www.etas.com/en/hotlines.php
The RTA hotline is available to all RTA-RTE users with a valid support contract.
rta.hotline.uk@etas.com
+44 (0)1904 562624. (0900-1730 GMT/BST)
Please provide support with the following information:
• Your support contract number.
• Your AUTOSAR XML and/or OS configuration files.
• The command line that results in an error message.
• The version of the ETAS tools you are using.
Contact, Support and Problem Reporting
277
RTA-RTE V6.2.0
Reference Manual
Index
--error-report, 57
Symbols
--exclusive-area-optimization, 58
--append-name-to-buffer, 23
--fast-init, 59, 250
--atomic-assign, 24
--file, 60
--bit-pack-type, 25
--force-basic-tasks, 61
--bsw-scope-limit-defns, 27
--have-64bit-int-types, 62, 257
--bsw-xml-namespace, 28
--help, 63
--bsw, 26
--implicit-allocation-method,
64,
--calibration-disable, 29
258
--calibration-instantiation, 30, 217
--implicit-read-return-const, 65
--calibration-method, 31, 196
--client-server-global-optimization, --implicit-use-global-buffers, 66
--incremental-build, 67
32
--initial-value-rounding, 68
--com-symbolic-sigs, 33
--ioc-header, 69
--com-version, 34
--ioc-xml-namespace, 70
--contract, 35
--local-mcsd, 71
--deviate-allow-supportsmulti-sharedmemorys,
--makedep, 72
40
--deviate-allow-unmapped-swci-config, --mcore-spinlocks-always, 73
--mcsd-policy, 74
36
--deviate-appl-impl-compu-method, 37 --measurement, 75
--deviate-appl-impl-display-format, --memory-sections, 76
--notimestamps, 77
38
--operating-system, 78
--deviate-bsw-any-partition, 39
--optimize, 79, 196
--deviate-enum-cast, 41
--os-define-osenv, 80
--deviate-group-calibration-none,
--os-fp, 81
42, 266, 267
--deviate-ignore-datatype-semantics, --os-header, 82
43
--os-output-param, 83
--deviate-implicit-cat2-mdd, 44
--os-permit-extended-tasks, 84
--deviate-implicit-modify-for-loopbacks,
--os-task-as-function, 85
45
--os-xml-namespace, 86
--deviate-memmap-decls, 46, 257
--output, 14, 19, 54, 87
--deviate-omit-implicit-cds, 47
--period, 88, 231
--deviate-physical-dimension-compatibility,
--preferred-intra-core-protection-scheme,
48
89
--deviate-prefer-no-empty-executions, --protection-threshold-copy-bytes,
49
90
--deviate-split-swci-support, 50
--quiet, 91
--deviate-task-sections, 51, 258
--report, 92
--rte, 93, 117
--deviate-trace-implicit-api, 52
--deviate-unconnected-pmode-behavior, --samples, 94, 256
53
--strict-config-check, 95
--diagnostic, 54
--strict-initial-values-check, 96
--disable-warning, 55, 109
--strict-unconnected-rport-check, 97
--error-as-warning, 56, 109
--sws, 98, 276
278
Index
RTA-RTE V6.2.0
Reference Manual
--task-recurrence, 99
--template-path, 100
--test-license, 101
--text-value-spec-policy, 102
--toolchain-significant-len, 103
--use-partition-sections, 104
--variability-also-bind, 105
--version, 106
--vfb-trace, 107, 196
--warn-directive, 108
--warning-as-error, 109
--xmlentity, 110, 114
--xmlschema, 110–112, 114
--, 22
A
AFL, 206
API
BSW API
Rte_GetMirror, 156
Rte_MainFunction, 231
Rte_NvMNotifyInitBlock, 156
Rte_NvMNotifyJobFinished, 156
Rte_SetMirror, 156
Rte_Start, 242
Rte_Stop, 242
Rte_Tick_Timeouts, 244
SWC API
Rte_Call, 215
Rte_CData, 217
Rte_DRead, 237
Rte_Enter, 218
Rte_Exit, 219
Rte_Feedback, 221
Rte_IFeedback, 220
Rte_IInvalidate, 222
Rte_Invalidate, 223
Rte_IRead, 224
Rte_IrTrigger, 245
Rte_IrvIRead, 226
Rte_IrvIWrite, 227
Rte_IrvRead, 228
Rte_IrvWrite, 229
Rte_IStatus, 230
Rte_IsUpdated, 230
Rte_IWrite, 225
Rte_IWriteRef, 225
Rte_MainFunction, 16, 88
Rte_Mode, 232
Rte_NPorts, 233
Rte_Pim, 235
Rte_Port, 234
Rte_Ports, 233
Rte_Prm, 216
Rte_Read, 236
Rte_Receive, 238
Rte_Result, 240
Rte_Send, 241
Rte_Switch, 243
Rte_Trigger, 245
Rte_Write, 246
ApplicationArrayDataType, 132
ApplicationPrimitiveDataType, 131
ApplicationRecordDataType, 132
ApplicationValueSpecification, 142
Array of curve/map
Calibration, 272
ArrayValueSpecification, 143
Assembly connector, 181
AUTOSAR, 9
Compiler_Cfg.h, 258
Formula Language, 206
Namespace, 112
Package, 117
Sub-package, 118
xml.xsd, 114
C
C Library, 15, 260
Calibration
Com-spec, 125, 126
Configuration, 29, 146, 166, 196
Data, 147
Init-RAM Structure, 269
Initial Values, 125, 126, 167
Instance name, 268
Method, 15, 31
Type name, 267
Client-server
Application Error, 148
Call point, 173
Com-spec, 130
Index
279
RTA-RTE V6.2.0
Reference Manual
-dv8aicm, see --deviate-appl-impl-compu-method
-dv8aidf, see --deviate-appl-impl-display-format
-dv8ausc, see --deviate-allow-unmapped-swci-config
-dv8bap, see --deviate-bsw-any-partition
-dv8ec, see --deviate-enum-cast
-dv8gcpn, see --deviate-group-calibration-none
-dv8ic2mdd, see --deviate-implicit-cat2-mdd
-dv8idts, see --deviate-ignore-datatype-semantics
-dv8imflb, see --deviate-implicit-modify-for-loopba
-dv8md, see --deviate-memmap-decls
-dv8omitcds, see --deviate-omit-implicit-cds
-dv8pdc, see --deviate-physical-dimension-compatibi
-dv8pnee, see --deviate-prefer-no-empty-executions
-dv8sss, see --deviate-split-swci-support
-dv8tia, see --deviate-trace-implicit-api
-dv8ts, see --deviate-task-sections
-dv8upb, see --deviate-unconnected-pmode-behavior
-dw, see --disable-warning
-eao, see --exclusive-area-optimization
-eaw, see --error-as-warning
-err, see --error-report
-fbt, see --force-basic-tasks
-fi, see --fast-init
-f, see --file
-h, see --help
-iam, see --implicit-allocation-method
-ib, see --incremental-build
D
-igb, see --implicit-use-global-buffers
DataTypeMappingSet, 140
-int64, see --have-64bit-int-types
Delegation connector, 181
-iochdr, see --ioc-header
Deprecated Command-line Options
-iocxmlns, see --ioc-xml-namespace
-O, see --optimize
-irrc, see --implicit-read-return-const
-aa, see --atomic-assign
-ivr, see --initial-value-rounding
-bpt, see --bit-pack-type
-l, see --local-mcsd
-bsld, see --bsw-scope-limit-defns
-mc, see --mcsd-policy
-bswxmlns, see --bsw-xml-namespace
-mem, see --memory-sections
-b, see --bsw
-ms, see --measurement
-cd, see --calibration-disable
-m, see --makedep
-ci, see --calibration-instantiation
-nts, see --notimestamps
-cm, see --calibration-method
-osenv, see --os-define-osenv
-csgo, see --client-server-global-optimization
-osfp, see --os-fp
-cv, see --com-version
-oshdr, see --os-header
-cy, see --com-symbolic-sigs
-osparam, see --os-output-param
-c, see --contract
-ospet, see --os-permit-extended-tasks
-diag, see --diagnostic
-osxmlns, see --os-xml-namespace
-dv8-constr2028, see --deviate-allow-supportsmulti-sharedmemorys
-os, see --operating-system
Configuration, 147, 187, 188
Port-Defined argument values, 169
RTE Event, 162
Command-line
Examples, 20
Options, 20
Command-line option
file, 60
Compiler Abstraction, 258
Component Prototype
Implementation, 192
Instantiation, 180
Mapping, 192
Composition
Assembly connector, 181
Configuration, 180
Delegation connector, 181
Port prototype, 182
Service connector, 182
CompuMethod
of Category IDENTICAL, 138
of Category LINEAR, 138
of Category RAT_FUNC, 139
of Category TEXTTABLE, 139
ConstantReference, 144
ConstantSpecification, 143
280
Index
RTA-RTE V6.2.0
Reference Manual
I
-o, see --output
Implementation (SWC), 177
-picps, see --preferred-intra-core-protection-scheme
Source/object code, 177
-ptcb, see --protection-threshold-copy-bytes
ImplementationDataType, 133
-p, see --period
of Category ARRAY, 136
-q, see --quiet
of Category STRUCTURE, 137
-rn, see --append-name-to-buffer
of Category TYPE_REFERENCE, 134
-rp, see --report
of Category VALUE, 135
-r, see --rte
ImplementationDataTypeElement, 138
-samples, see --samples
Implicit
-scc, see --strict-config-check
-siv, see --strict-initial-values-checkreception, 171
transmission, 171
-spla, see --mcore-spinlocks-always
IncludedDataTypeSet,
144
-sws, see --sws
Indirect API, 169
-tf, see --os-task-as-function
Instance handle, 213
-tl, see --test-license
Inter-ECU
-tp, see --template-path
PDU Type, 179
-tr, see --task-recurrence
-tsl, see --toolchain-significant-len System signal, 178
System signal group, 179
-ups, see --use-partition-sections
Inter-runnable variables
-ur, see --strict-unconnected-rport-check
Configuration, 165
-vab, see --variability-also-bind
Read, 176
-vt, see --vfb-trace
Write, 176
-v, see --version
Interface, 145
-warn, see --warn-directive
Calibration, 146
-we, see --warning-as-error
Client-server, 147
-xe, see --xmlentity
Nv-Data, 146
-xs, see --xmlschema
-, see --, see --text-value-spec-policy Sender-receiver, 145
Internal Behavior
E
Calibration, 166
ECU Description, 193
Exclusive area, 165
ECU Type
Inter-runnable variables, 165
Configuration, 180
Multiple instantiation, 177
Instance, 182
NVRAM mapping, 166
ECUC, 9
Port option, 168
Error messages, 18
Runnable entity, 170
Exclusive areas, 175
Internal behavior, 158
Configuration, 165
RTE Event, 159
Invocation, 11
F
Exit codes, 18
Files
Rte.err, 57
M
Filter, 128
McSupportData, 272
force-basic semantics, 61
Measurement
forced-basic semantics, 196
Configuration, 75, 149
Global enable, 15, 196
Formula Language, 206
Index
281
RTA-RTE V6.2.0
Reference Manual
Schema, 153
memcpy, 15, 260
Memory Mapping, 256
Generating Rte_MemMap.h, 256
Mode dependency, 164
Mode Manager, 173
Mode manager
Acknowledgment, 124
Com-spec, 124
Mode Switch
Asynchronous, 125, 243
Synchronous, 243
Mode user
Com-spec, 125
Modes
Configuration, 158
N
Namespace
Add new, 112
Supported, 112
nativeDeclaration, 136
NumericalValueSpecification, 142
Nv-Data
Configuration, 146
NVRAM, see also BSW API
Callback API, 156
Nv-Block Data Mapping, 153
Read Access, 155
Role Based Port Assignment, 156
Write Access, 155
NVRAM mapping, 166
O
Optimization, 79
Configuration, 196
VFB tracing, 255
Os
Alarm, 262
Counters, 16, 262
Events, 262
Resources, 261
Os config, 194
Output
Console, 17, 57
Error messages, 18
File, 57
282
Index
Output files, 11
Application header, 12
Basic Software Module Description
file, 13
COM config, 13, 14
McSupportData file, 13
OS config, 13, 14, 16, 260
Rte.c, 12
Rte.err, 13
Rte.h, 12
Rte_Cbk.h, 12
Rte_Cfg.h, 251
Rte_Const.h, 12, 15, 19, 251, 261, 262
Rte_Hook.h, 12
Rte_Intl.h, 12
Rte_Lib.c, 19
Rte_lib.c, 12
Rte_Main.h, 12
Rte_Type.h, 12, 264, 267
Task body, 13
P
PDU Type
Configuration, 179
Phase
BSW, 26
Configuration, 195
Contract, 35
LocalMCSD, 71
RTE, 93, 251
Port
Configuration, 120
Port-Defined argument values, 169
Port-options, 168
Indirect API, 169
Take address, 169
Pure runnable, 170
R
RecordValueSpecification, 143
Reference
Absolute, 115
ECU Instance, 117
Instance, 116
Relative, 115
RTA-OSEK, 9
RTE, 9
RTA-RTE V6.2.0
Reference Manual
Configuration, 112, 194
Namespace, 212
RTE API, see API
RTE Event
Asynchronous Server Call Returns,
162, 248
Data Receive Error, 160, 248
Data Received, 160, 248
Data Send Completed, 161, 248
Mode dependency, 164
Mode Switch, 163, 248
Mode Switched Ack, 248
Mode Switched Acknowledge, 163
Operation Invoked, 162, 248
Timing, 159, 249
RTE Library, 19
Rte_Activity, 262
Rte_Instance, 213
RTE_LIBC_MEMCPY, 15, 19
Rte_memcpy, 15, 260
Rte_PortHandle, 214
Rte_ScheduleTable, 261
Rte_Tick_Counter, 262
Rte_Timeout, 263
Rte_TOut_Counter, 262
Rte_UserCfg.h, 19
RTE_VFB_TRACE, 251
RteForceBasicTask, 196
Runnable, 170
Blocking API, 174
Call point, 173
Data read access, 171
Data write access, 171
Exclusive areas, 175
Minimum start interval, 176
Mode switch, 173
Re-entrant, 170
Read variables, 176
Receive point, 172
Send point, 172
Signature, 249
Symbol, 174
Waitpoint, 174
Written variables, 176
Runnable Entity Mapping, 198
S
Sender-receiver
Acknowledgment, 123
Alive timeout, 127
Com-spec, 123, 126
Configuration, 145, 185
Filter, 128
Initial Value, 128
Initial Values, 123
Invalid value, 124, 142
Invalidation, 128
Receive point, 172
RTE Event, 160, 161
Send point, 172
Timeout, 123
Services
Reference, 198
Splitable stereotype, 209
Std_ReturnType, 214
SWC Type
Configuration, 118
Implementation, 177
Instantiation, 180, 197
Multiple instantiation, 177
Naming, 212
Port, 120
System
Configuration, 184
System signal
Configuration, 178
Reference to, 180
System signal group
Configuration, 179
T
TextTableMapping, 141
typeEmitter, 134
U
Unit, 141
User Configuration File, 19
V
VFB Trace
COM Notification, 253
Configuration, 251
OS Task Activation, 253
Index
283
RTA-RTE V6.2.0
Reference Manual
OS Task Dispatch, 253
OS Task Set Event, 253
OS Task Wait Event, 253
OS Task Wait Event Return, 253
RTE API Return, 252
RTE API Start, 251
Runnable Invocation, 254
Runnable Termination, 254
Signal Reception, 252
Signal Transmission, 252
VFB Tracing
Configuration, 107, 195
W
284
Index
Wait point, 174
X
XML, 9
Adding a new namespace, 112
Caching, 113
Entity Resolution, 114
Entity Resolver, 110
Merge, 118
schemaLocation, 111, 112
Splitable Elements, 118
Support namespaces, 112
Vendor specific, 201
xml.xsd, 114
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising