SW C And System Ing Guide AUTOSAR TR SWCing
AUTOSAR_TR_SWCingGuide
AUTOSAR_TR_SWCingGuide
AUTOSAR_TR_SWCingGuide
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 53
| Download | |
| Open PDF In Browser | View PDF |
SW-C and System Modeling Guide AUTOSAR Release 4.2.2 Document Title SW-C and System Modeling Guide Document Owner Document Responsibility Document Identification No Document Classification AUTOSAR AUTOSAR 207 Auxiliary Document Status Part of AUTOSAR Release Final 4.2.2 Document Change History Release Changed by 4.2.2 AUTOSAR Release Management 4.2.1 AUTOSAR Release Management 4.1.1 AUTOSAR Administration 4.0.3 AUTOSAR Administration Change Description System Level description introduced in the CompositionSWComponents domain. IDENTICAL CompuMethods modeling rules aligned to ASAM representation. Complete traceability towards Modeling Requirements Document. Generic CompuMethods reuse mechanism enhanced through new modeling rules Extended naming rules and recommendations for Long Names standardization Extended description of blueprint mechanism applied to Application Interfaces Domain Document’s scope extended to support rules for Long Names. Rules and recommendations defined for Long Names standardizations. Rules defined to support multiple meaning of keyword abbreviations. Support reuse of CompuMethods for specific resolutions. Extended structure of blueprintable packages Description of “Blueprint” mechanism and its impact on Blueprintable elements in Application Interfaces domain New Autosar Application Interfaces Package Structure Keywords handling reformulated according to the Standardization Template specification and the new Application Interfaces Packages Structure “Units” section enhanced and new “Physical Dimensions” section introduced 1 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 Document Change History Release Changed by 3.1.5 AUTOSAR Administration 3.1.4 AUTOSAR Administration 3.1.1 AUTOSAR Administration AUTOSAR Administration 3.0.1 Change Description Modeling rules optimization for multiple instances. New description of the standardized Autosar packages structure. New RTE specification and requirements references introduced. Set of modelling rules changed to allow different styles of modelling with respect to clustering and future extensibility. Set of naming convention rules changed to allow more flexibility in creation of self-explicable names. Name and number of standardized ARPackages have changed. Scope of naming convention has been extended accordingly. Blueprints concept supported as a dedicated AR-Package for Ports Long Names are now out of scope Legal disclaimer revised Legal disclaimer revised Initial Release 2 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 Disclaimer This specification and the material contained in it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the companies that have contributed to it shall not be liable for any use of the specification. The material contained in this specification is protected by copyright and other types of Intellectual Property Rights. The commercial exploitation of the material contained in this specification requires a license to such Intellectual Property Rights. This specification may be utilized or reproduced without any modification, in any form or by any means, for informational purposes only. For any other purpose, no part of the specification may be utilized or reproduced, in any form or by any means, without permission in writing from the publisher. The AUTOSAR specifications have been developed for automotive applications only. They have neither been developed, nor tested for non-automotive applications. The word AUTOSAR and the AUTOSAR logo are registered trademarks. Advice for users AUTOSAR specifications may contain exemplary items (exemplary reference models, "use cases", and/or references to exemplary technical solutions, devices, processes or software). Any such exemplary items are contained in the specifications for illustration purposes only, and they themselves are not part of the AUTOSAR Standard. Neither their presence in such specifications, nor any later documentation of AUTOSAR conformance of products actually implementing such exemplary items, imply that intellectual property rights covering such exemplary items are licensed under the same rules as applicable to the AUTOSAR Standard. 3 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 Table of Contents 1 2 3 References ...........................................................................................................7 Scope ...................................................................................................................8 How to read this document ...................................................................................9 3.1 Conventions used ..........................................................................................9 3.2 Acronyms and Abbreviations .......................................................................10 4 Requirements traceability ...................................................................................11 5 Modeling Rules ...................................................................................................15 5.1 Reuse of model element..............................................................................15 5.1.1 Reuse of one interface for multiple ports ............................................. 15 5.1.2 Reuse of one data type for multiple interfaces .................................... 16 5.2 Use of multiple ComponentPrototypes ........................................................17 5.3 Clustering ....................................................................................................17 5.3.1 Clustering through Sender Receiver Interfaces ................................... 18 5.4 Future extensibility ......................................................................................18 6 Naming Convention for AUTOSAR Model Elements ..........................................21 6.1 General Rules for Long Names ...................................................................21 6.2 General Rules for Short Names ..................................................................22 6.3 Relation between Model Level and the Implementation Level .....................24 6.3.1 Length Restrictions.............................................................................. 24 6.3.2 Data Types .......................................................................................... 24 6.3.3 RTE rules of name mapping ................................................................ 24 6.3.4 Components and Ports........................................................................ 26 6.3.5 Sender Receiver Interfaces and Data Elements ................................. 28 6.3.6 Client Server Interfaces, Operations, and Arguments ......................... 29 6.4 Usage of Keywords .....................................................................................29 6.4.1 Keyword Composition Semantic Rules ............................................... 30 6.5 Model Elements ...........................................................................................36 6.5.1 ARPackage (AR-PACKAGE) .............................................................. 36 6.5.2 SenderReceiverInterface (SENDER-RECEIVER-INTERFACE) ......... 37 6.5.3 VariableDataPrototype (VARIABLE-DATA-PROTOTYPE) ................. 38 6.5.4 ApplicationDataType ........................................................................... 40 6.5.5 CompuMethod (COMPU-METHOD) ................................................... 41 6.5.6 SwComponentType (COMPOSITION-SW-COMPONENT-TYPE) ...... 42 6.5.7 System (SYSTEM) .............................................................................. 44 6.5.8 SwComponentPrototype (SW-COMPONENT-PROTOTYPE)............. 45 6.5.9 PortPrototype (P-PORT-PROTOTYPE, R-PORT-PROTOTYPE) ....... 45 6.5.10 Units (UNIT) ........................................................................................ 46 6.5.11 Physical Dimensions ........................................................................... 47 6.5.12 Enumerations ...................................................................................... 47 6.5.13 ClientServerInterface (CLIENT-SERVER-INTERFACE) ..................... 49 6.5.14 ParameterInterface (PARAMETER-INTERFACE) .............................. 49 6.5.15 ParameterDataPrototype (PARAMETER-DATA-PROTOTYPE) ......... 50 6.5.16 DataConstrs (DATA-CONSTRS) ......................................................... 50 6.5.17 Blueprintable Elements in Application Interfaces Domain ................... 50 6.5.18 PortPrototypeBlueprint (PORT-PROTOTYPE-BLUEPRINT) .............. 51 6.5.19 Keywords ............................................................................................ 53 4 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 5 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 List of Tables Table 1 Example of keywords abbreviation of common usage ..........................32 Table 2 Fields ...........................................................................................................33 Table 3 Category of ARPackages ...........................................................................37 6 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 1 References [1] Template UML Profile and Modeling Guide AUTOSAR_TemplateModelingGuide.pdf [2] Specification of RTE Software AUTOSAR_SWS_RTE.pdf [3] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate.pdf [4] AUTOSAR Model Persistence Rules for XML AUTOSAR_TR_XMLPersistenceRules.pdf [5] MISRA-C: 2004. Guidelines for the use of the C language in critical systems. [6] Autosar Methodology AUTOSAR_TR_Methodology.pdf [7] Generic Structure Template AUTOSAR_TPS_GenericStructureTemplate.pdf [8] Requirements on Runtime Environment AUTOSAR_SRS_RTE.pdf [9] Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf [10] Requirements for Software Component Modeling AUTOSAR_RS_SWCModeling.pdf [11] AUTOSAR System Template AUTOSAR_TPS_SystemTemplate.pdf 7 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 2 Scope The limits of my language mean the limits of my world. Ludwig Wittgenstein This document gives guidelines and conventions on using the AUTOSAR model elements in order to build AUTOSAR systems. It does not contain guidelines for the AUTOSAR meta model. This is already covered by [1]. 8 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 3 How to read this document All rules are identified by an ID. The ID starts with “TR_SWMG_” for the Modeling Rules followed by four digits (TR_SWMG_xxxx). The ID starts with “TR_SWNR_” for the Naming Rules followed by four digits (TR_SWNR_xxxx). The provided XML examples conform to the AUTOSAR metamodel. 3.1 Conventions used In requirements, the following specific semantics are used (taken from Request for Comment RFC 2119 from the Internet Engineering Task Force IETF) The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Note that the requirement level of the document in which they are used modifies the force of these words. MUST: This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. MUST NOT: This phrase, or the phrase „SHALL NOT“, means that the definition is an absolute prohibition of the specification. SHOULD: This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. SHOULD NOT: This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. MAY: This word, or the adjective „OPTIONAL“, means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation, which does not include a particular option, MUST be prepared to interoperate with another implementation, which does include the option, though perhaps with reduced functionality. In the same vein an implementation, which does include a particular option, MUST be prepared to interoperate with another implementation, which does not include the option (except, of course, for the feature the option provides.) 9 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 3.2 Acronyms and Abbreviations API: AR: CAN: ECU: HMI: MISRA: RTE: SW-C: WP: XML: Application Programming Interface AUTOSAR Controller Area Network Electronic Control Unit Human Machine Interface Motor Industry Software Reliability Association Real Time Environment Software Component Work Package eXtensible Markup Language 10 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 4 Requirements traceability Requirements against this document are exclusively stated in the corresponding requirements document [10]. The following table references the requirements specified in [10] and provides information about individual specification items that fulfill a given requirement. Requirement Satisfied by [RS_SWMG_00001] Distinguish Standardized vs. not standardized model elements of type ARElement [RS_SWMG_00002] Name should reflect the purpose of the model element [RS_SWMG_00005] [RS_SWMG_00006] Easy creation of names Model Elements names shall be selfexplanatory [RS_SWMG_00007] Distinguish model elements of different model element suppliers of not standardized model elements [RS_SWMG_00010] Model Element Names shall follow semantic rules 11 of 53 [TR_SWMG_00003] [TR_SWMG_00004] [TR_SWMG_00017] [TR_SWMG_00018] [TR_SWNR_00022] [TR_SWNR_00023] [TR_SWMG_00009] [TR_SWMG_00011] [TR_SWNR_00004] [TR_SWNR_00006] [TR_SWNR_00010] [TR_SWMG_00009] [TR_SWMG_00011] [TR_SWNR_00004] [TR_SWNR_00006] [TR_SWNR_00037] [TR_SWMG_00003] [TR_SWMG_00004] [TR_SWMG_00017] [TR_SWNR_00059] [TR_SWMG_00010] [TR_SWMG_00011] [TR_SWMG_00012] [TR_SWMG_00013] [TR_SWMG_00014] [TR_SWMG_00015] [TR_SWMG_00016] [TR_SWMG_00019] [TR_SWNR_00005] [TR_SWNR_00008] [TR_SWNR_00026] [TR_SWNR_00027] [TR_SWNR_00029] [TR_SWNR_00040] [TR_SWNR_00041] [TR_SWNR_00042] [TR_SWNR_00043] [TR_SWNR_00044] [TR_SWNR_00051] [TR_SWNR_00055] [TR_SWNR_00056] [TR_SWNR_00057] [TR_SWNR_00062] Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 [RS_SWMG_00011] Model Element Names are composed by arranging standardized keywords [RS_SWMG_00012] Semantic of Model Element Names shall allow variable number of keywords [RS_SWMG_00014] Length restriction for short names of Identifiable Names shall allow to indicate if the value is a direct measurement or a conditioned value Names should follow the ISO 8855 for English naming Use English as Standard Language for Names [RS_SWMG_00016] [RS_SWMG_00017] [RS_SWMG_00030] [RS_SWMG_00031] [RS_SWMG_00034] [RS_SWMG_00039] [RS_SWMG_00040] [RS_SWMG_00041] [RS_SWMG_00048] [RS_SWMG_00049] [RS_SWMG_00052] [RS_SWMG_00053] [RS_SWMG_00054] [TR_SWNR_00069] [TR_SWNR_00070] [TR_SWNR_00071] [TR_SWNR_00009] [TR_SWNR_00010] [TR_SWNR_00011] [TR_SWNR_00013] [TR_SWNR_00018] [TR_SWNR_00066] [TR_SWNR_00019] [TR_SWNR_00020] [TR_SWNR_00034] [TR_SWNR_00050] [TR_SWNR_00058] [TR_SWNR_00002] [TR_SWNR_00019] [TR_SWNR_00058] [TR_SWNR_00001] [TR_SWNR_00001] [TR_SWNR_00013] No Architectural Information in Names [TR_SWNR_00007] [TR_SWNR_00035] [TR_SWNR_00036] [TR_SWNR_00048] Usage of Unique Keywords [TR_SWNR_00066] [TR_SWNR_00067] [TR_SWNR_00068] Avoid usage of Trailing underscores [TR_SWNR_00003] Avoid sequences of underscores characters [TR_SWNR_00003] [TR_SWNR_00009] Do not rely on uppercase/lowercase [TR_SWNR_00004] difference only [TR_SWNR_00011] Easy lookup of names in databases [TR_SWMG_00008] Support Identifiable already present in the [TR_SWMG_00018] MasterTable Definition of Package Structure Model shall be compliant to the Meta Model Provide guidelines how to resolve name conflicts 12 of 53 [TR_SWMG_00008] [TR_SWMG_00001] [TR_SWNR_00001] [TR_SWNR_00002] [TR_SWNR_00003] [TR_SWNR_00004] [TR_SWNR_00005] [TR_SWNR_00006] [TR_SWNR_00007] [TR_SWNR_00008] [TR_SWNR_00009] [TR_SWNR_00010] [TR_SWNR_00011] Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 [RS_SWMG_00055] [RS_SWMG_00056] [RS_SWMG_00057] [RS_SWMG_00059] [RS_SWMG_00060] [RS_SWMG_00061] [TR_SWNR_00013] [TR_SWNR_00017] [TR_SWNR_00018] [TR_SWNR_00019] [TR_SWNR_00020] [TR_SWNR_00022] [TR_SWNR_00023] [TR_SWNR_00026] [TR_SWNR_00027] [TR_SWNR_00029] [TR_SWNR_00034] [TR_SWNR_00035] [TR_SWNR_00036] [TR_SWNR_00037] [TR_SWNR_00040] [TR_SWNR_00041] [TR_SWNR_00042] [TR_SWNR_00043] [TR_SWNR_00044] [TR_SWNR_00048] [TR_SWNR_00050] [TR_SWNR_00051] [TR_SWNR_00055] [TR_SWNR_00056] [TR_SWNR_00057] [TR_SWNR_00058] [TR_SWNR_00059] [TR_SWNR_00062] [TR_SWNR_00063] [TR_SWNR_00064] [TR_SWNR_00065] [TR_SWNR_00066] [TR_SWNR_00067] [TR_SWNR_00068] [TR_SWNR_00069] [TR_SWNR_00070] [TR_SWNR_00071] Continuous Data Type resolution should be [TR_SWMG_00004] a power of two Standardized model elements shall not contain non standardized elements Modeling Guide shall support the AUTOSAR methodology Provide Single Set of Keywords Applicability of Naming Convention Naming convention shall be unique 13 of 53 [TR_SWMG_00003] [TR_SWMG_00004] [TR_SWMG_00017] [TR_SWNR_00022] [TR_SWMG_00001] [TR_SWNR_00010] [TR_SWNR_00059] [TR_SWNR_00001] [TR_SWNR_00002] [TR_SWNR_00003] [TR_SWNR_00004] Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 [RS_SWMG_00062] [TR_SWNR_00005] [TR_SWNR_00006] [TR_SWNR_00007] [TR_SWNR_00063] [TR_SWNR_00064] [TR_SWNR_00065] Naming Convention shall rule Short Names [TR_SWNR_00001] and Long Names construction. [TR_SWNR_00002] [TR_SWNR_00050] [TR_SWNR_00063] [TR_SWNR_00064] [TR_SWNR_00065] 14 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 5 Modeling Rules [TR_SWMG_00001] Compliance to Autosar Meta Model ⌈ Model shall be compliant to the Meta Model.⌋( RS_SWMG_00053 , RS_SWMG_00057) [TR_SWMG_00003] Usage of AR Package concept for SW-Cs ⌈ Use AR Package concept for SW-C to distinguish different suppliers of SW-C. This helps to trace SW-C supplier in case of errors due to the usage of elements not part of the released AUTOSAR Packages.⌋ ( RS_SWMG_00001 , RS_SWMG_00007 , RS_SWMG_00056) [TR_SWMG_00017] Usage of AR Package category ⌈ Use AR Package category to distinguish what is standardized, according to the provider of the ARPackage, from what is not.⌋ ( RS_SWMG_00001, RS_SWMG_00007 , RS_SWMG_00056) See document [7] for AR Package categories classification. [TR_SWMG_00004] Separate packages for elements not defined by AUTOSAR partnership ⌈ Each element not defined by the AUTOSAR partnership, shall be included in a AR Package different from the one officially released by AUTOSAR, i.e. the AR Package ShortName shall be changed (e.g. SUPPLIER1) and the category may be changed or not according to AR packages category classification and stakeholder specific standard elements handling.⌋ ( RS_SWMG_00001 , RS_SWMG_00007 , RS_SWMG_00055 , RS_SWMG_00056) Recommendations: - continuous Data Type resolution should be a power of two. 5.1 Reuse of model element 5.1.1 Reuse of one interface for multiple ports The reuse of interfaces is encouraged. Example: The Temperature interface is used for the OutsideTemperature port of a component type. InsideTemperature port and [TR_SWMG_00011] Independence of Interfaces definition from variants ⌈ Do not define different interfaces to implement variants. Define one interface that is independent on the variant and define several ports using this interface which are dependent on the variant.⌋ ( RS_SWMG_00002 , RS_SWMG_00006 , RS_SWMG_00010) Using one interface for multiple ports makes variant handling more understandable since the interfaces are not affected by the variant. Ports can be enabled or disabled depending on the selected variant. 15 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 Example: Gasoline spark ignition engine management systems know the concept of a slow path and a fast path for torque intervention. Current diesel systems do not know this distinction. The following modeling is not recommended: Define an interface TorqueInterventionSlow and an interface TorqueInterventionFast. Define a port TorqeInterventionSlow with the interface TorqueInterventionSlow and a port TorqueInterventionFast with the interface TorqueInterventionFast. In a diesel variant the TorqueInterventionSlow port and interface are ignored. The following modeling is recommended: Define an interface TorqueIntervention1. Define a port TorqueInterventionSlow and a port TorqueInterventionFast which both have the interface TorqueIntervention1. In a diesel variant the TorqueInterventionSlow port is disabled. EngineControl EngineControl TorqueIntervention1 (gasoline variant) AtomicSoftwareComponent TorqueInterventionFast PortInterface PPort PPort TorqueInterventionSlow ComponentPrototype EngineControl (diesel variant) TorqueInterventionFast PPort ComponentPrototype Figure 1: Re-use of PortInterfaces in Ports with variants. Please note that in the example, as result of variant handling approach, the two ComponentPrototypes are of the same ComponentType. 5.1.2 Reuse of one data type for multiple interfaces The reuse of data types is encouraged. Example: The Torque data type is used in the Data Elements of the interfaces MinimumTorqueAtClutch and MaximumTorqueAtClutch. 16 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 5.2 Use of multiple ComponentPrototypes If the same port P (either RPort or PPort) of multiple ComponentPrototypes A 1..n of the same ComponentType is connected to another ComponentPrototype B, the name of the ports should be constructed by concatenating the name of the connected ComponentPrototype Ai and the name of the connected port P. It is recommended to do the concatenation by means of a preposition (see chapter 6) in the following order:+ +[ ] Example: The “Washer” ComponentType has an RPort “Activation”. There are three ComponentPrototypes of this type: “WasherFront”, “WasherRear”, and “WasherHeadlamp”. The WiperWasherManager ComponentType should have separate PPorts that are connected to the RPorts of the three ComponentPrototypes. These PPorts should have the names “ActivationOfWasherFront”, “ActivationOfWasherRear”, and “ActivationOfWasherHeadlamp”. WiperWasherMgr WiperWasherMgr WasherFront Washer AtomicSoftwareComponet AtomicSoftwareComponent ActivationOfWasherFront PPort RPort Activation ComponentPrototype WasherRear PPort RPort Activation ActivationOfWasherRear ComponentPrototype WasherHeadlamp PPort RPort ActivationOfWasherHeadlamp ComponentPrototype Activation ComponentPrototype Figure 2: Ports of multiple ComponentPrototypes. 5.3 Clustering [TR_SWMG_00008] Clustering ⌈ also be represented in the RS_SWMG_00052) Functional elements that belong together shall model together. ⌋ ( RS_SWMG_00048 , 17 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 The AUTOSAR meta model provides several features to support clustering of model elements. For example, interfaces can contain multiple data elements, record data types and array data types can contain multiple elements. The use of structuring features improves the structure and comprehensibility of the model. 5.3.1 Clustering through Sender Receiver Interfaces If elements are clustered through Sender receiver Interfaces there is a choice between using three alternatives that have different behaviors and usually fit to different application scenarios: A) record data types, elements of a record are transmitted atomically (in one block). elements of record data types can have different data types. B) array data types elements of arrays are transmitted atomically (in one block), all elements of an array have to use the same data type. C) interfaces with multiple data elements. The data elements of interfaces are transmitted separately. Data elements of interfaces can have different data types. Examples for usage of these three alternatives are: To A): use a record data type that includes the o status and its value that belong together, e.g. for an actuator o wheel dependent information that belong together, o axle dependant information that belong together, o value(s) and their derivation(s). To B): use an array data type o sending of dynamic configuration data, e.g. engine full-load curve, or retarder brake torque curve which may change when vehicle is driven, depending on temperature or altitude. This use case is common in commercial vehicles J1939 bus protocol on CAN. To C): data that belongs together with independent update times: o default for most signals, allows the system configurator most flexibility in scheduling communication. The advantage to use a record instead of an array data type is that a separate name for each element is used. 5.4 Future extensibility It is often necessary to adapt and extend model elements to cope with new requirements. Defining or standardizing elements named “Reserved” (or with other names indicating a project dependent solution) with undefined meaning as placeholders for future 18 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 extensions would lead to non standardized elements when customization is performed at a project level. [TR_SWMG_00009] Placeholder model elements with undefined meaning not allowed ⌈ Placeholder model elements with undefined meaning are not allowed. ⌋ ( RS_SWMG_00002 , RS_SWMG_00006 ) The following rules ensure forward compatibility of relevant model elements towards new AUTOSAR releases. [TR_SWMG_00010] Standardized Enumeration DataTypes names differentiation ⌈ If a new application requires the modification of any attribute (Enumeration Values, Enumeration Value Names) of a standardized enumeration data type, the existing data type shall not be changed, but a new enumeration data type shall be created. The name of the new data type shall differ from the name of the original data type only in the sequence number. ⌋ ( RS_SWMG_00010) [TR_SWMG_00012] Standardized Continuous Datatypes names differentiation ⌈ If a new application requires the modification of any attribute (Resolution, Physical Limits, Offset, Unit) of a standardized continuous data type, the existing data type shall not be changed, but a new continuous data type shall be created. The name of the new data type shall differ from the name of the original data type only in the sequence number. ⌋ ( RS_SWMG_00010) [TR_SWMG_00013] Standardized Array DataTypes names differentiation ⌈ If a new application requires the modification of any attribute (number of elements, type of elements) of a standardized array data type, the existing data type shall not be changed, but a new array data type shall be created. The name of the new data type shall differ from the name of the original data type only in the sequence number. ⌋ ( RS_SWMG_00010) [TR_SWMG_00014] Standardized Record Datatypes names differentiation ⌈ If a new application requires the modification of any attribute (Number of Elements, Elements Name, Elements Type) of a standardized record data type, the existing data type shall not be changed, but a new record data type shall be created. The name of the new data type shall differ from the name of the original data type only in the sequence number. ⌋ ( RS_SWMG_00010) [TR_SWMG_00015] Standardized Sender-Receiver Interfaces names differentiation ⌈ If a new application requires the modification of any attribute (number of data elements, name of the data elements, type of the data elements) of a standardized sender-receiver interface, the existing interface shall not be changed, but a new sender-receiver interface shall be created. The name of the new interface shall differ from the name of the original interface only in the sequence number. ⌋ ( RS_SWMG_00010) [TR_SWMG_00016] Standardized Client-Server Interfaces names differentiation ⌈ If a new application requires the modification of any attribute (operation name, number of arguments, argument names, argument data types, argument in/out 19 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 property) of a standardized client-server interface, the existing interface shall not be changed, but a new interface shall be created. The name of the new interface shall differ from the name of the original interface only in the sequence number. ⌋ ( RS_SWMG_00010) [TR_SWMG_00019] Standardized PortPrototypeBlueprints names differentiation ⌈ If a new application requires the modification of the name (shortname) of a standardized PortPrototypeBlueprint, or any change in the referenced elements (port interfaces, application data types, unit) the existing PortPrototypeBlueprint shall not be changed, but a new PortPrototypeBlueprint shall be created. The name (shortname) of the new PortPrototypeBlueprint shall differ from the name of the original PortPrototypeBlueprint only in the sequence number. Changes in the descriptive elements of the PortPrototypeBlueprint (description, longname, introduction) not necessary lead to a new version of the PortPrototypeBlueprint except when the meaning of the original element is modified.⌋ ( RS_SWMG_00010) 20 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 6 Naming Convention for AUTOSAR Model Elements This section contains naming conventions for AUTOSAR model elements. This naming convention is applicable in any vehicle application domain of AUTOSAR. [TR_SWNR_00059] Scope of naming convention ⌈ The naming convention applies to the following Model Elements: SwComponentTypes SwComponentPrototypes ApplicationDataTypes Units PhysicalDimensions PortInterfaces PortPrototypeBlueprints PortPrototypes DataPrototypes CompuMethods DataConstrs Keywords ⌋ ( RS_SWMG_00007 , RS_SWMG_00054 , RS_SWMG_00060) The XML code which is shown in the document is compliant to the AUTOSAR schema xsd. The Naming Convention defined in this document focus on defining rules for building contents of three main Autosar metamodel elements 1. attribute longName, derived from the abstract class MultilanguageReferrable 2. attribute shortName, derived from to the abstract class Referrable 3. keywords and keywords abbreviations Attributes longName and shortName are common to all Autosar elements listed in TR_SWNR_00059. The concept of keyword abbreviation is rather closed to the keyword class definition [9] and will be discussed in chapter 6.4 6.1 General Rules for Long Names According to 7 Long Names (attribute longName) are targeted to humans readers and could be expressed in different languages. They contain the headline of the objects as single line text. [TR_SWNR_00063] Mandatory Long Names in Application Inerfaces context ⌈ In the context of Application Interfaces Domain longName is a mandatory attribute even if its multiplicity is 0..1 in the Autosar MetaModel.⌋ ( RS_SWMG_00054 , RS_SWMG_00061 , RS_SWMG_00062) [TR_SWNR_00064] Capital and lower letters in Long Name construction ⌈ order to improve readability: 21 of 53 In Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 Every first word of a long name shall start with a capital letter. Articles (e.g. “a”, “the”), Prepositions (e.g. “at”, “by”, “to”) and Conjunctions (e.g. “and”, “or”) shall be expressed by small letters. All other words in the text line shall start with a capital letter.⌋ ( RS_SWMG_00054 , RS_SWMG_00061 , RS_SWMG_00062) [TR_SWNR_00065] Usage of spaces in Long Name construction ⌈ The Usage of spaces between words shall be mandatory .⌋ ( RS_SWMG_00054 , RS_SWMG_00061 , RS_SWMG_00062) Additionally some specific recommendations are strongly suggested when dealing with long names constructions: Usage of abbreviations: Abbreviations should be avoided as much as possible. If required, only wellknown abbreviations should be used in long names. If present, all the abbreviations need to be explained in the description. Abbreviations for functionalities and systems should use the long name of the keywords (e.g. “ABS”). If the abbreviation is not very well known, put it into brackets, e.g. “Application Interfaces, (AI)”. Long Names constructions: Long names should not contain tailing numbers/sequence number in order to avoid the same long names for several entries The base of a long name should be the extended form of the short name. Order of words may be changed and additional terms may be added. Single terms may be exchanged in order to increase understandability. Maximal length of a long name should be limited to 80 characters, according to 7. Exception: Long names of keywords follow different rules, see chapter 6.4.1. 6.2 General Rules for Short Names In this chapter and in the rest of the document from now on, the term “name” refers to “short name” only. [TR_SWNR_00001] The language for the names shall be English ⌈ The language for the names shall be English.⌋ ( RS_SWMG_00017 , RS_SWMG_00030 , RS_SWMG_00054 , RS_SWMG_00061 , RS_SWMG_00062) A model element name shows up as a SHORT-NAME in XML in, for example: MyName According to the rules for AUTOSAR XML files the short name has the type AR:IDENTIFIER (see document [4]) and is restricted by the following regular expression: [a-zA-Z][a-zA-Z0-9_]{0,127} 22 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 [TR_SWNR_00002] Length of Short Names ⌈ A short name shall be between 1 and 128 characters long, shall begin with an alphabet, and shall consists of alphabets and numbers. ⌋ ( RS_SWMG_00014 , RS_SWMG_00054 , RS_SWMG_00061 , RS_SWMG_00062) [TR_SWNR_00003] Forbidden usage of underscores in Short Names ⌈ As additional requirement to the MetaModel, underscores are not allowed in the short names.⌋ ( RS_SWMG_00039 , RS_SWMG_00040 , RS_SWMG_00054 , RS_SWMG_00061) Rules TR_SWNR_00002 and TR_SWNR_00003 lead to the following regular expression for short names: [a-zA-Z][a-zA-Z0-9]{0,127} [TR_SWNR_00004] Differentiation based on capitalization not allowed ⌈ Within one name space ShortNames shall not differ in capitalization only.⌋ ( RS_SWMG_00002 , RS_SWMG_00006 , RS_SWMG_00041 , RS_SWMG_00054 , RS_SWMG_00061) Do not distinguish names only from uppercase/lowercase format since the user can easily mix up names that differ only for capitalization. The following example lists not allowed name differentiation: Short name 1: DoorLocked Short name 2: doorLocked [TR_SWNR_00005] Valid identifier in source code for C, C++ and Cpreprocessor ⌈ A name must be usable as valid identifier in source code for C, C++ and C-preprocessor. ⌋ ( RS_SWMG_00010 , RS_SWMG_00054 , RS_SWMG_00061) The rationale behind this rule is, that some of the names are used by code generators, especially the RTE generator, to produce source code symbols. Since it would be difficult to state for each individual name if and in which context it will ever be used by generators, this general restriction is made. [TR_SWNR_00006] Short Names meaning ⌈ The names of elements shall document their meaning or use.⌋ ( RS_SWMG_00002 , RS_SWMG_00006 , RS_SWMG_00054, RS_SWMG_00061) [TR_SWNR_00007] Usage of prefixes to identify kind of element not allowed ⌈ No prefixes related to the kind of the element shall be used in the name of the model elements covered by this Naming Convention, listed in TR_SWNR_00059.⌋ ( RS_SWMG_00031 , RS_SWMG_00054 , RS_SWMG_00061) Reasons for not using prefixes: Shorter names, e.g. if it shows up in the RTE API in names as RTE_... If we had any prefix for e.g. interfaces, prefixes would have to be defined for all elements (ports, SWCs, data types,...). 23 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 Prefixes can be introduced by code generators for the identifiers of programming language APIs. The information, whether some element is a Component, DataType, Interface, etc., is already contained in the structure of the XML file. 6.3 Relation between Model Level and the Implementation Level This section describes the relation between the model level of AUTOSAR and the implementation level. A “model” in this chapter means an AUTOSAR model, i.e., an instance of the AUTOSAR meta model. “Implementation” means the realization of the model in a programming language, like C. For a more detailed explanation please refers to AUTOSAR Methodology document [6]. 6.3.1 Length Restrictions The RTE Specification [2] contains rules on how to map model-level names to generated names on implementation-level. For example, an implementation-level name for a sender/receiver implicit write is created as follows: Rte_IWrite__ _ This name is visible to the linker as an external identifier. MISRA [5] rule 1.4 requires that the significant part of such a name shall not exceed 31 chars. Since AUTOSAR decided to allow a deviation from this rule, the size of the generated name can exceed 31. Taking into account that each single name from the model cannot exceed 128 characters, the name given above could have as much as 10 + 1 + 128 + 1 +128 + 1 + 128 = 397 characters. 6.3.2 Data Types [TR_SWNR_00008] Data type names shall conform to C/C++ names for typedefs ⌈ Data type names in an AUTOSAR model shall conform to C/C++ names for typedefs (e.g. they shall not be C keywords).⌋ ( RS_SWMG_00010 , RS_SWMG_00054) . 6.3.3 RTE rules of name mapping The following RTE requirements describe the mapping from modeling level to implementation level: SWS_Rte_1153 SWS_Rte_3837 24 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 Such SWS_Rte rules define the sequence in which model element ShortNames are concatenated to obtain generated function names in the RTE C Code. Example: 1 ShortName of component type: Wshr ShortName of the component prototype: WshrFrnt ShortName of runnable entity: Monr ShortName of provide port: OutdT ShortName of sender-receiver interface of this port: T1 ShortName the data element: Val Examples of generated function names for rule SWS_Rte_3837: Rte_IRead_Monr_OutdT_Val Rte_IRead_Wshr_Monr_OutdT_Val 1 The keywords and keyword abbreviations used in this example may not be consistent to the keyword list. 25 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 6.3.4 Components and Ports Composition SwComponentPrototype 2 SwComponentPrototype 1 SwComponentPrototype Name (typed by SwComponentType) - will not appear in the source code (but in the header file and the binary interface) - will be used as part of the file name of the header file - Is local to an AUTOSAR package - is local to a CompositionSWComponentType pp1 rp1 pp2 rp2 rp1 pp1 rp2 Port Name - will appear in the source code - is local to a SWComponentType (in the role of CompositionSWComponentType) SwComponentPrototype 3 pp1 pp2 rp3 Figure 3: Components and ports The abstract SwComponentType cannot be instantiated, there can only be either a CompositionSwComponentType, a ParameterSwComponentType or a specialized inherited class of the AtomicSwComponentType class. See [3] for more details. Such AtomicSwComponentTypes encapsulate the implementation of their functionality and behavior and merely expose well-defined connection points, called PortPrototypes, to the outside world. 26 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 CompositionSwComponentType, which are SwComponentTypes as well, may be aggregated in further CompositionSwComponentTypes, and their purpose is to allow existing software components aggregation. In a CompositionSwComponentType the SwComponentTypes are occurring in specific roles which are called SwComponetPrototypes. The figure above shows the scope of Components and Ports names. SwComponentTypes names are local to an AR-Package therefore within an ARPackage there must not be two SwComponentTypes having the same name, i.e, the short-names shall be unique. This is explicitly required by RTE implementation since RTE generator rejects those configurations where multiple SwComponentTypes have the same short name (see [SWS_Rte_7190] in [2] for more details) The same applies for: SwComponentPrototypes within a CompositionSwComponentType PortPrototypes within a SwComponentType. See document [3] for detailed information on name space provided by Software Components. Port names will appear in the RTE APIs, see RTE specifications [2]. The figure also shows that names of connected ports can be different (example: pp2 from Component3 connected to rp3 of Component2). 27 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 6.3.5 Sender Receiver Interfaces and Data Elements Figure 4: SenderReceiverInterfaces and Data Elements The figure above shows the scope of SenderReceiverInterfaces and Data Elements names. Interface names are local to an AR-Package therefore within an AR-Package there must not be two Interfaces having the same name, i.e, the short-names shall be unique. The same applies for Data Elements i.e. within an Interface, Data Element names shall be unique. See document [3] for detailed information on name space provided by Sender Receiver Interfaces. Data Element names will appear in the RTE APIs, see RTE specifications [2]. 28 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 6.3.6 Client Server Interfaces, Operations, and Arguments Figure 5: ClientServerInterfaces and Operations The figure above shows the scope of ClientServerInterfaces, Operations, and Argument names. Interface names are local to an AR-Package therefore within an AR-Package there must not be two Interfaces having the same name, i.e, the short-names shall be unique. The same applies for: Operations within a ClientServerInterface. Arguments within an Operation. See document [3] for detailed information on name space provided by Client Server Interfaces. Data Element names will appear in the RTE APIs, see RTE specifications [2]. 6.4 Usage of Keywords Depending on its role in the component design, short names for component types, ports, port interfaces or data elements can make use of the predefined keywords and their abbreviations, which are described in more detail in 6.4.1. The advantage is, that this results in relatively short names with established meaning. 29 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 6.4.1 Keyword Composition Semantic Rules According to [9] each keyword is described by the following attributes: shortName: represent the unique name of the keyword, it’s not involved in name construction longName: represent the long form of the keyword desc: represent the definition of the keyword introduction: verbal description of the use case (not used at the moment) abbrName: specifies the abbreviated name of the keyword and it’s used to build shortNames classification: describe the semantic field of the keyword (MeanEnvironment-Device, Action-PhysicalType, Condition-Qualifier, Index, Preposition) If not differently specified in the rest of the document the term keyword will refer to the longName of the keyword, while the abbreviated name could be referred as “abbrName attribute” or “keyword abbreviation” as well. Example: Definition of keyword describing the driver of a vehicle longName : Driver abbrName: Drvr Usecases (shortName of ports using abbrName attribute): DrvrProf, DrvrDoorLockSt [TR_SWNR_00009] Invalid usage of underscores for keywords separation ⌈ No underscores shall be used to separate keyword abbreviations (abbrName attribute) in short names, because the RTE uses them to separate port names from Data Element names. Instead of underscores capital letters shall be used to separate the keyword abbreviations.⌋ ( RS_SWMG_00011 , RS_SWMG_00040 , RS_SWMG_00054) [TR_SWNR_00010] Building Short Names with Keywords ⌈ Short names are composed by concatenating predefined keyword abbreviations (abbrName attribute). ⌋ ( RS_SWMG_00005 , RS_SWMG_00011 , RS_SWMG_00054 , RS_SWMG_00059) [TR_SWNR_00011] Each keyword shall start with an uppercase letter, or a number, followed by lowercase letters or “-” ⌈ Each keyword shall start with an uppercase letter, or a number, followed by lowercase letters or “-”. ⌋ ( RS_SWMG_00011 , RS_SWMG_00041 , RS_SWMG_00054) Examples: Keyword abbreviation (abbrName): “Apil”, Long Name of Keyword: “A-Pillar” [TR_SWNR_00013] English as language for Keywords definition ⌈ A keyword shall be a single English word or a multiplier prefix, such as “kilo”, “giga” or “milli”. To shorten the names within maximum allowed numbers of characters keyword 30 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 abbreviations (abbrName attribute) are RS_SWMG_00030 , RS_SWMG_00054) provided. ⌋ ( RS_SWMG_00011 , [TR_SWNR_00018] Rule for keyword abbreviation definition ⌈ A keyword abbreviation (abbrName attribute) shall not be a valid single English word unless the meanings of the keyword and the English word are the same. This avoids potential misunderstanding while reading short names.⌋ ( RS_SWMG_00011 , RS_SWMG_00054) The following example is not a valid short name, because non-abbreviated keywords are used: EngineSpd. The correct short name would be: EngSpd. It could happen that some keywords which are different in their longName form need to be abbreviated in the same way, since different scientific or technical communities usually adopt well-know and wide accepted acronyms or abbreviations in their domain. These acronyms and abbreviations can be tha exactly the same, even if representing different contentsAccording to the definition of keyword class in [9] multiple meaning for keyword abbreviations can be handled by the following set of three rules (TR_SWNR_00066, TR_SWNR_00067 andTR_SWNR_00068) [TR_SWNR_00066] Defined attributes of Keywords in Application Interfaces context ⌈ Each keyword shall have exactly one shortName, exactly one longName, exactly one desc, exactly one abbrName and exactly one classification.⌋ ( RS_SWMG_00011 , RS_SWMG_00034 , RS_SWMG_00054) [TR_SWNR_00067] Multiple meanings through abbrName attribute ⌈ Two or more different keywords can share the same abbrName.⌋ ( RS_SWMG_00034 , RS_SWMG_00054) According to [7] and [9], if an Identifiable element is contained into another Identifiable element, the shortName of the contained Identifiable element shall be unique into the context of the Identifiable element that contains it (in this case Keywords are identifiable elements contained into the identifiable element KeywordSet) As a consequence, each shortName shall be unique in the KeywordSet. If keywords share the same abbrName it is recommended to use abbrName plus index for the shortName. [TR_SWNR_00068] Rule for shortNames keywords definition in case of multiple meanings ⌈ If a keyword abbreviation (attribute abbrName) is intended to have N different meanings, N keywords (elements belonging to the class Keyword) sharing the same value of abbrName attribute shall be present and each different meaning shall be described into the corresponding keyword desc attribute. ⌋ ( RS_SWMG_00034 , RS_SWMG_00054) Example: shortName longName abbrName desc classification Ch (*) Charge Ch ………. Condition/qualifier 31 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 Ch1 (*) Channel Ch ………. Condition/qualifier (*) this example doesn’t represent the current implementation but just one possible implementation preserving the uniqueness of the shortnames into the keywords package [TR_SWNR_00017] Special Keywords as well-known acronyms ⌈ Some terms of common usage in the automotive environment cannot be expressed by a single English word. In such a case the abbreviation (abbrName) and the keyword (longName) shall be identical except for camelcase and adding “-”.⌋ ( RS_SWMG_00054) Examples: Keyword abbr.: “Abs”, Long Name of Keyword: “ABS” Keyword abbr.: “Nox”, Long Name of Keyword: “NOx” As an exception for the long name definition, in case of terms of common usage and well known acronyms (mainly keywords belonging to the set of keywords ruled by TR_SWNR_00017), the long name of the keyword can be expressed entirely by capital letters. Examples: Keyword Engine ABS Keyword Abbreviation DefinitionEnglish Eng Engine Abs Antilock Braking System Table 1 Example of keywords abbreviation of common usage [TR_SWNR_00058] Semantic rules for readable and understandable names ⌈ In order to build readable and understandable names, keywords shall be arranged according to semantic rules. Such rules define Semantic Fields that must be used in a defined sequence: 32 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 Sequence Semantic Field Name 1 MeanEnvironmentDevice 2 ActionPhysical Type 3 ConditionQualifier 4 5 Index Preposition Description Physical mean, environment. Define the element subject of ActionPhysicalType. Action or physical type conditioning or modifying the MeanEnvironmentDevice. Qualifies the MeanEnvironmentDevice or ActionPhysicalType in terms of data flow, event issuing or expresses a particular condition of the signal in terms of numeric treatment, time validity, precision quality, location. Identifies the signal as part of a logically structured information. Can be used to identify elements multiply instanced (index) or section of information. Used for joining/separating complex naming patterns made by several semantic fields Rules and Examples It shall be a noun. It can be also a compound definition. Abbreviation or acronym cannot end with a digit. Examples for Mean: Fuel Examples for Environment: Air, Ambient Examples for Device: Accelerator, AcceleratorPedal, Engine The Action shall be a verb. The Physical Type shall be a noun. It can be also a compound. Abbreviation or acronym cannot end with a digit. Examples for Action: Move, Pull, Release, Lock, OpenClose, ShiftUp Examples for Physical Type: Temperature, Speed It shall be a noun or an adjective. It can be also a compound definition. Abbreviation or acronym cannot end with a digit. Examples for Condition: Absolute, Old, New, AbsoluteEstimated, Examples for Qualifier: Request, Command, Status It shall be a number, a single character, or an adjective describing the part. When used, it is always the last keyword in the sequence: Examples for Index: BrakeSwitch1 Example: EngSpdAndPosn CoolgReqFromSteer TqActAtClu Table 2 Fields All the predefined keywords and their corresponding keyword abbreviations are classified according to the semantic fields. This is specified using the classification attribute.⌋ ( RS_SWMG_00012 , RS_SWMG_00016 , RS_SWMG_00054) Semantic fields are concatenated according to the Sequence column numbering: Mean-Environment-DeviceAction-PhysicalTypeCondition-QualifierIndex this sequence is called FieldBlock. 33 of 53 - Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 [TR_SWNR_00019] Sematic fields not mandatory ⌈ None of the semantic fields are mandatory and semantic fields can be repeated, i.e. names can be built by using an arbitrary number of semantic fields.⌋ ( RS_SWMG_00012 , RS_SWMG_00016 , RS_SWMG_00054) [TR_SWNR_00020] Indexes start with number ⌈ Only keywords classified as Index shall start with a number. When used, Index field is always the last in the field block.⌋ ( RS_SWMG_00012 , RS_SWMG_00054) The following examples are valid short names2: GearAct MirrMoveCmd EngSpd EngSpdMax Recommendation: if a semantic field contains more than one keyword they either have to be arranged in a natural English order or the most important keyword has to come first. Example: BrakePedalStatus PedalBrake is not recommended, since “brake pedal” is a very well-known English term. Other examples of compound definitions where not all semantic fields are present: BrkPedlSwt1 VehBodyAVertBasMeasd OpenClsReq AcvDamprSt To increase readability of names, a list of predefined Prepositions is provided within the standardized keyword list. [TR_SWNR_00034] Arbitrary number of field blocks ⌈ An arbitrary number of field blocks can be concatenated.⌋ ( RS_SWMG_00012 , RS_SWMG_00054) However, the number of field blocks should be limited. It is encouraged to separate each field block by adding an appropriate preposition. This leads to the following naming pattern: Mean-Environment-DeviceAction-PhysicalTypeConditionQualifierIndexPrepositionMean-Environment-DeviceActionPhysicalTypeCondition-QualifierIndexPreposition … Portion of names separated by prepositions are called FieldBlocks: 2 The keywords and keyword abbreviations used in the examples of this chapter may not be consistent to the keyword list 34 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 FieldBlock1Preposition1FieldBlock2Preposition2…FieldBlockN. The following example shows the usage of prepositions: EngSpdAtGearTar It’s strongly recommended that each FieldBlock has a meaning independent of the other FieldBlocks. Example: The interface with the description “Generic interface for total powertrain torque at wheels” can not be represented by “PtTqAtWhlsTot”. The FieldBlock “WhlsTot” has not the intended meaning, because “Tot” relates to “Tq”. Therefore, one of the possible compliant solutions for the name is “PtTqTotAtWhls”. [TR_SWNR_00050] Order of FieldBlocks in case of usage of prepositions ⌈ If one or more prepositions are used to build a short name the most essential / important element has to be in the FieldBlock1. FieldBlocks that are following are refining the before mentioned FieldBlock. ⌋ ( RS_SWMG_00012 , RS_SWMG_00054, RS_SWMG_00062) TR_SWNR_00050 ensures that the names start with most essential information and end with very special details. Example: The following interface description: “Driver request torque limitation if accelerator and brake pedal pressed at the same time and implausibilities have occurred.” would result in the following name: DrvrTqLimnReqForBrkAccrPedlImpy1. The whole interface describes a driver torque limitation request. Therefore, DrvrTqLimnReq is the most important FieldBlock. Hence it is the first FieldBlock. The following examples show incorrect names: Naming a PortPrototype: MaximumEngineSpeed causes a keyword sequence error: Condition-Qualifier keyword cannot precede Mean-Environment-Device keyword. The correct sequencing is: EngineSpeedMaximum. 35 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 6.5 Model Elements The naming conventions apply to the ShortName (SHORT-NAME) attribute of the element. The element must be a specialization of Identifiable. The elements are referred to by their meta-model name. The names in brackets are the XML element names. To come to a reasonable naming conventions, for each element the objectives of the convention are described first. 6.5.1 ARPackage (AR-PACKAGE) An ARPackage creates a name space3. In one system package names have to be unique. Packages can have sub-packages. The following rules are defined for the standardized package structure: [TR_SWNR_00022] ARPackage AUTOSAR ⌈ According to [7], chapter 3, below the root an ARPackage with LongName AUTOSAR and ShortName AUTOSAR shall be placed. Everything inside the top-level package AUTOSAR is released by the AUTOSAR partnership (see requirements RS_SWMG_00001, RS_SWMG_00056). The top-level package LongName and ShortName AUTOSAR is reserved by the AUTOSAR partnership and shall not be used elsewhere.⌋ ( RS_SWMG_00001 , RS_SWMG_00054, RS_SWMG_00056) [TR_SWNR_00023] Packages contained into ARPackage AUTOSAR ⌈ Within this ARPackage “AUTOSAR” the following packages are contained (ShortNames): AISpecification, ApplicationDataTypes_Blueprint, CompuMethods_Blueprint, DataConstrs_Blueprint, PortInterfaces_Blueprint, PortPrototypeBlueprints_Blueprint, Collections_Blueprint, KeywordSets_Blueprint, ApplicationDataTypes_Example, BlueprintMappingSets_Example, CompuMethods_Example, DataConstrs_Example, PortInterfaces_Example, SwComponentTypes_Example, PhysicalDimensions, Units, LifeCycleInfoSets, Systems.⌋ ( RS_SWMG_00001 , RS_SWMG_00054) These rules define the standardized package structure for the defined elements of the M2 [1] modeling level. According to requirement RS_SWMG_00056 the AUTOSAR package is a reserved name space. [TR_SWMG_00018] Policy of names standardization ⌈ Only elements which are defined by the AUTOSAR partnership shall be added to this name space. These elements shall not be modified (see [7])⌋ ( RS_SWMG_00001 , RS_SWMG_00049) 3 For a description of the name space concept see [4]. 36 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 The following figure shows an example for the resulting standardized package structure . Figure 6: AUTOSAR Package structure As recommendation, names of non standardized AUTOSAR packages should follow the general rules defined in chapter 6.4.1. ARPackage AUTOSAR does not have a category, while its sub-packages do. Categories of the sub-packages are set as follows: ARPackage PhysicalDimensions Units LifeCycleInfoSets DataConstrs_Blueprint ApplicationDataTypes_Blueprint CompuMethods_Blueprint PortInterfaces_Blueprint PortPrototypeBlueprints_Blueprint KeywordSets_Blueprint Collections_Blueprint ApplicationDataTypes_Example BlueprintMappingSets_Example CompuMethods_Example PortInterfaces_Example SwComponentTypes_Example DataConstrs_Example Systems Category STANDARD STANDARD STANDARD BLUEPRINT BLUEPRINT BLUEPRINT BLUEPRINT BLUEPRINT BLUEPRINT BLUEPRINT EXAMPLE EXAMPLE EXAMPLE EXAMPLE EXAMPLE EXAMPLE EXAMPLE Table 3 Category of ARPackages 6.5.2 SenderReceiverInterface (SENDER-RECEIVER-INTERFACE) [TR_SWNR_00051] Usage of sequence number in the Sender-Receiver Interfaces names ⌈ The interface name shall end with a sequence number to take 37 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 into account the RS_SWMG_00054) future evolution of interfaces.⌋ ( RS_SWMG_00010 , The rule TR_SWNR_00051 for interfaces is similar to TR_SWNR_00044 for data types. Example: Package1 …..Composition ……… SwComponentPrototype1 …….SwComponentPrototype1 … SwComponentPrototype1 ...….. pp1 …….Interface1 Recommendations: A SenderReceiverInterface should be a reusable element. The name should be independent of its concrete usage by components and ports and should only reflect its general purpose. To allow reuse, the communication path (the indication of source or destination of ports using the interface) should not be encoded in the interface name. The following short names are bad examples for interface names: YawRateStdByEsc YawRateStdBySecCtrlrYawRate The interface name in this example shall be “YawRate1” and reused by two ports whose names could be “YawRateStdByEsc” and “YawRateStdBySecCtrlrYawRate”. 6.5.3 VariableDataPrototype (VARIABLE-DATA-PROTOTYPE) Objectives: Should only be significant relative to the SenderReceiverInterface. Shall be a unique name per SenderReceiverInterface. Rules: [TR_SWNR_00026] Name reflecting data content ⌈ The name shall reflect the content of the data. If no sensible name for the data element can be found 38 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 and the interface is used to indicate a data transfer, it is recommended to use the name Val (abbreviation of Value).⌋ ( RS_SWMG_00010 , RS_SWMG_00054) Example: BattU1 Battery Voltage This interface provides the actual voltage level as measured at the battery. false BattU U1 [TR_SWNR_00027] Name reflecting operation ⌈ If the data element prototype contains no value information, but an operation, the name shall reflect the operation that is driven by the data element prototype.⌋ ( RS_SWMG_00010 , RS_SWMG_00054) Example: Cls (abbreviation of Close). If no sensible name for the data element prototype can be found and the interface is used to indicate an operation, the name Oper (abbreviation of Operation) should be used. [TR_SWNR_00029] Multiple data denoting same operations ⌈ If the SenderReceiverInterface contains more than one data element prototype denoting the same operation, a “Mean-Environment-Device” keyword must be used to differentiate the operations. (Here “operation” is not used in the sense of ClientServerInterface operations, but as an operation or action which is triggered by a SenderReceiver communication. “Operation” is also not identical to the semantic field “Action”.)⌋ ( RS_SWMG_00010 , RS_SWMG_00054) Example: UserTransmit UsrTx TelegramTransmit TelgrmTx ExteriorLightDisplay ExtrLiDisp ParkingLightDisplay PrkgLiDisp Remark: In the last two examples all keywords are classified as “MeanEnvironment-Device” so they can be arranged in any order Recommendations: Repeating the name of the enclosing interface in the name of the data element is allowed, but not recommended. Repetition of the name would result in redundant information and would reflect negatively in RTE generated function names (see chapter 6.3.3 for an example of distribution of information between interface name and data element name). 39 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 6.5.4 ApplicationDataType The following classes are subclasses of the class ApplicationDataType in the AUTOSAR meta model. Therefore, the naming convention applies also to these classes: ApplicationPrimitiveDataType (APPLICATION-PRIMITIVE-DATA-TYPE) ApplicationRecordDataType (APPLICATION-RECORD-DATA-TYPE) ApplicationArrayDataType (APPLICATION-ARRAY-DATA-TYPE) Rules: [TR_SWNR_00056] The name shall reflect the meaning of the type ⌈ The name shall reflect the meaning of the type.⌋ ( RS_SWMG_00010 , RS_SWMG_00054) [TR_SWNR_00057] Usage of prefixes not allowed ⌈ No prefixes, such as “t_” shall be used in the type name.⌋ ( RS_SWMG_00010 , RS_SWMG_00054) [TR_SWNR_00055] Information about array length not allowed in names ⌈ No numbers shall be used in an ApplicationArrayDataType name to specify its length.⌋ ( RS_SWMG_00010 , RS_SWMG_00054) [TR_SWNR_00044] Usage of sequence number in the datatypes names ⌈ The data type name shall end with a sequence number to take into account the future evolution. This rule shall also be applied to distinguish data types, which represent the same physical entity, but with different ranges or resolution i.e. names of such data types shall differ only for the sequence number.⌋ ( RS_SWMG_00010 , RS_SWMG_00054) Example: Temperature1 Temperature2 Temperature3 T1 T2 T3 The rules TR_SWNR_00044 ensures the reusability of the data types. [TR_SWNR_00048] No information about communication in names ⌈ To allow reuse, the communication path shall not be encoded in the data type name.⌋ ( RS_SWMG_00031 , RS_SWMG_00054) Example XML: 40 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 Val T1 6.5.5 CompuMethod (COMPU-METHOD) COMPU-METHOD shortnames elements fullfill naming convention rules. Specific name patterns shall be followed in order to distinguish special use cases: [TR_SWNR_00069] Generic CompuMethod per Unit for category IDENTICAL ⌈ Generic CompuMethod per Unit for category IDENTICAL shall follow the following pattern: {shortName of Unit}Identcl RS_SWMG_00054) (mandatory)⌋ ( RS_SWMG_00010 , [TR_SWNR_00070] Generic CompuMethod per Unit for category LINEAR ⌈ Generic CompuMethod per Unit for category LINEAR (to support reuse of CompuMethods for specific resolutions) shall follow the following pattern: {shortName of Unit}Lnr{sequence number} (mandatory after release 4.2.1 for new compuMethod creation)⌋ ( RS_SWMG_00010 , RS_SWMG_00054) [TR_SWNR_00071] Generic CompuMethod for category TEXTTABLE ⌈ Generic CompuMethod for category TEXTTABLE (typically used for enumeration types) shall follow the following pattern: {shortName of the corresponding ApplicationDataType} RS_SWMG_00010 , RS_SWMG_00054) (mandatory)⌋ ( Examples: 1) IDENTICAL CompuMethod (as it would be for float implementation, no compu scales required) U1 Voltage 1 Generic data type for voltage VALUE READ-ONLY U1 U1 0.1 Volt 41 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 2) LINEAR CompuMethod KelvinIdentcl Kelvin Identical IDENTICAL Kelvin 3) TEXTTABLE CompuMethod (for Enumeration datatype) VoltLnr1 Voltage 1 Generic data type for voltage LINEAR Volt 0 25.2 0 1 0.1 6.5.6 SwComponentType (COMPOSITION-SW-COMPONENT-TYPE) The naming convention applies to the following subclasses of the class SwComponentType: ApplicationSwComponentType CompositionSwComponentType SensorActuatorSwComponentType ParameterSwComponentType 42 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 Objectives: Avoid name clashes within the package Classification of components Not for component prototypes (see 6.5.7) Rules [TR_SWNR_00035] Prefixes referring specific domains not allowed for SwComponentTypes ⌈ Using a prefix to indicate the application domain (such as powertrain, body, chassis) of the SwComponentType is not allowed. ⌋ ( RS_SWMG_00031 , RS_SWMG_00054) Recommendations: Use a noun or concatenation of nouns. Example SensorSpeed SnsrSpd The name should be understandable. Examples VehicleSpeed VehicleMotionDemand WiperWasher VehSpd VehMtnDmd WiprWshr Example (to shorten the example, some lines have been removed): AckSt1 Acknowledge Status 1 TEXTTABLE NoUnit 0 = NotAcpt (Request not accepted.) 0 0 NotAcpt 1 = Acpt (Request accepted.) 1 1 Acpt DrvrDoorKeypad DrvrDoorKeypad KeyPadMgr SwComponentPrototype KeyPadOfLidRe KeyPad SwComponentType Figure 7: Example of SwComponentType 6.5.7 System (SYSTEM) Even if not in the scope of this document, it’s important to know that the top level element of an AUTOSAR System Description is represented by the System element. The System description defines five major elements: Topology, Software, Communication, Mapping and Mapping, Constraints. With respect to [11] and [3], in AUTOSAR, Software Components can either be atomic or may consist of a composition of other Software Components and CompositionSwComponentType. In order to assemble non-trivial applications from AUTOSAR components, such compositions can be built up hierarchically, until the outermost CompositionSwComponentType forms a kind of top-level composition. The System element directly aggregates the root software composition, containing all software components in the System in a hierarchical structure. This element is not required when the System description is used for a network-only use-case. Moreover, for the purpose of this document the System element always references the highest level of SW Compsitiojn, called TopLv (Top Level), and can be modeled just once. KeyPad …some ports skipped DrvrDoorKeyPad Driver Door Keypad Request to activate central locking master from the driver door key pad LockgCenReq1 KeyPadOfLidRe Rear Lid Keypad Request to activate central locking master on the rear lid from lid key pad LockgCenReq1 KeyPadMgr KeyPadManager Key Pad Manager KeyPadMgr ….some delegation ports skipped delcon_0 43 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 KeyPad/KeyPadMgr KeyPadMgr/DrvrDoorKeyPad KeyPad/DrvrDoorKeyPad 6.5.8 SwComponentPrototype (SW-COMPONENT-PROTOTYPE) Objectives of naming conventions for component prototypes (which are the instances of each component type): avoid name clashes within the composition classification of components These names are not used within the API to the RTE. Rules: [TR_SWNR_00036] Prefixes referring specific domains not allowed for SwComponentPrototypes ⌈ Using a prefix to indicate the application domain (such as powertrain, body, chassis) of the SwComponentPrototype is not allowed.⌋ ( RS_SWMG_00031 , RS_SWMG_00054) Recommendations: The name should be understandable. In case a composition contains more than one instance of the same component type, the prototype name should reflect the role of this specific instance in the composition. An example on how to name multiple SwComponentPrototypes is given in section 5.2. Example: DoorLe, DoorRi Example: Systems EXAMPLE 44 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 SwComponentTypes false false false /AUTOSAR/AISpecification/SwComponentTypes_Example System SYSTEM_DESCRIPTION TopLvl TopLvl 6.5.9 PortPrototype (P-PORT-PROTOTYPE, R-PORT-PROTOTYPE) Objectives: should only be significant relative to the SW component (e.g. left, right etc.) 45 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 unique name per component PortProtoypes can be connected as long as they are typed with compatible PortInterfaces. Please refer to document [3] for such compatibility rules. Example: Short-Name: EmgyLockg MgrOfMirrAdjAutReqByUsr ManagerOfMirrorAdjustmentAutomaticRequestByUser Component treating the Automatic mirror movement requests - memory recall. MgrOfMirrAdjAutReqByUsr 6.5.10 Units (UNIT) Objectives: Shall be unique. Rules: [TR_SWNR_00040] Formulas containing “x to power of 2” ⌈ If the unit is a formula containing “x to the power of 2” the short name shall contain “Sqd” (abbreviation of keyword “Squared”).⌋ ( RS_SWMG_00010 , RS_SWMG_00054) [TR_SWNR_00041] Formulas containing “x to power of 3” ⌈ If the unit is a formula containing “x to the power of 3” the short name shall contain “Cubd” (abbreviation of keyword “Cubed”).⌋ ( RS_SWMG_00010 , RS_SWMG_00054) [TR_SWNR_00042] Formulas containing “x to power greater than 3” ⌈ If the unit is a formula containing “x to the power of number >3” the short name shall contain ToPwrOf EmgyLockg Emergency Locking User request for emergency locking in case of danger. LockUnlckReq1 .⌋ ( RS_SWMG_00010 , RS_SWMG_00054) [TR_SWNR_00043] Formulas containing division ⌈ If the unit is a formula containing a division the short name shall contain “Per”⌋ ( RS_SWMG_00010 , RS_SWMG_00054) Examples: NwtPerMtr Newton Per Meter surface tension (derived from SI units) N/m 1 M1TiNeg2 6.5.11 Physical Dimensions Physical Dimensions are used to entirely describe and classify elements inside the Units Package. Each unit’s physical dimension is represented as generic combination of one or more base physical quantities: electrical current, luminous intensity, time, mass, amount of substance, thermodynamic temperature, length or no-dimension, with specific exponents. Physical Dimensions Shortnames are built using a sequence of base physical quantities keyword abbreviations followed by numbers as exponents (“Neg” keyword abbreviation shall be used for negative number). Space character is not allowed inside shortname. Following the same base physical quantities sequence, Physical Dimensions Longnames are built using keywords (instead of abbreviations), numbers as exponents (minus sign for negative numbers is mandatory), and space between each physical quantity’s keyword and its exponent Example: Unit: Nm/s Physical Dimension: [L]2[M]1[T]-3 Shortname: NwtMtrPerSec Longname: Newton Meter Per Second MtrPerSecCubd Meter Per Second Cubed jerk (derived from SI units), also called jolt (esp. in British English), surge or lurch, is the rate of change of acceleration; more precisely, the derivative of acceleration with respect to time, the second derivative of velocity, or the third derivative of displacement. m/s^3 46 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.21 Len1TiNeg3 6.5.12 Enumerations There is no explicit support for enumeration types in the metamodel. Enumerations are modeled by using a DataType and a CompuMethod. Example: Len2M1TiNeg3 Length 2 Mass 1 Time -3 2 1 -3 UsrReqForWipg1 User Request For Wiping It represents the selection of the interval time or the speed of the wiper requested by the user. The exact timings and wipe speeds are not standardized and need therefore to be parameterized. VALUE 47 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 READ-ONLY UsrReqForWipg1 UsrReqForWipg1 In the Application Domain, but not only, a common use case is representing by the existence of two or more enumeration datatypes sharing the same enumeration label with different value: e.g: enum datatype CluSt1 defines Opend = 0 enum datatype LockSt2 defines Opend = 1 In order to allow the definition of different enumeration datatypes sharing the same enumeration labels but with different point range, the RTE layer provides a specific mechanism to solve configuration errors that otherwise would arise. This is also necessary in order to handle enumeration constants supplied by Basic Software modules which all use their own prefix convention. Such Enumeration constant names have to be unique in the whole AUTOSAR system. Skipping implementation details of the RTE layer (please see [2]), it can be resumed that before generating the final code the RTE combines some specific information coming from the CompuMethod used for the enumeration datatype definition and 48 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 other specific information derived from the set of data that each SW-C declares to use. All these information guarantee the uniqueness of the enumeration labels into the software architecture. If the set of information required by the RTE is not complete, the RTE generator shall reject this input as an invalid configuration. 6.5.13 ClientServerInterface (CLIENT-SERVER-INTERFACE) While modeling a ClientServerInterface, names for the following attributes shall be also defined: OperationPrototype ArgumentPrototype Rules: [TR_SWNR_00062] Usage of sequence number in the Client-Server Interfaces names ⌈ The interface name shall end with a sequence number to take into account the future evolution of interfaces.⌋ ( RS_SWMG_00010 , RS_SWMG_00054) The name of OperationPrototype attribute shall follow rule TR_SWNR_00029 in place for VariableDataPrototype (see 6.5.3) The name of ArgumentPrototype attribute shall follow all the rules in place for VariableDataPrototype (see 6.5.3) Recommendations: A ClientServerInterface should be a reusable element. The name of interface should be independent of its concrete usage by components and ports and should only reflect its general purpose. To allow reuse, the communication path (the indication of source or destination of ports using the interface) shall not be encoded in the interface name. The name of ArgumentPrototype attribute should follow all the recommendation in place for VariableDataPrototype (see 6.5.3) The name of OperationPrototype attribute should start with a keyword classified as “Action / Physical Type” Example for OperationPrototype: Short-Name: SetEveSt 6.5.14 ParameterInterface (PARAMETER-INTERFACE) To this model element, same rules and SenderReceiverInterface (see chapter 6.5.2) apply. 49 of 53 recommendations as for Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 6.5.15 ParameterDataPrototype (PARAMETER-DATA-PROTOTYPE) Objectives: Should only be significant relative to the ParameterInterface. Shall be a unique name per ParameterInterface. To this model element, same rules and VariableDataPrototype (see chapter 6.5.3) apply. recommendations as for 6.5.16 DataConstrs (DATA-CONSTRS) DATA-CONSTRS shortname elements fullfill naming convention rules.. Example: UsrReqForWipg1 User Request For Wiping TEXTTABLE 4 = UsrReqForWipgSpdHi 4 4 UsrReqForWipgSpdHi 2 = UsrReqForWipgIntl 2 2 UsrReqForWipgIntl 3 = UsrReqForWipgSpdLo 3 3 UsrReqForWipgSpdLo 0 = UsrReqForWipgOff 0 0 UsrReqForWipgOff 1 = WipgStrikeSngReqByUsr 1 1 WipgStrikeSngReqByUsr Flg1 /DATA-CONSTR> 6.5.17 Blueprintable Elements in Application Interfaces Domain AUTOSAR metamodel provides and supports mechanism to allow users to create and expand model elements starting from a well defined model elements base. Its goal is to provide the possibility of deriving elements with enhancing features and attributes that can be used in different contexts (e.g series projects).(for more details and for a complete definition of Blueprint mechanism and meta model UML classes at each AUTOSAR level, please refer to [9]) This blueprint mechanism is mainly based on three entities : Blueprint: acts as the predefinition of the element. Basically it follows the same structure as the derived elements. Blueprinted Element: acts as the element which was derived from the Blueprint. These elements are derived from blueprints mainly by copy and refine. This "refine" may add further attribute values’ Blueprint Mapping: acts as a reference between blueprints and their derived elements. The main purpose of this blueprint mapping is the ability to validate for each derived elements that they conform the the blueprint. Focusing on the Application Interfaces domain the goal is to promote the reuse of model elements outside the scope of SwComponentType. 50 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 Blueprintable elements are collected into a sort of stand alone elements library from which derived elements (for example PortPrototypes) can be created, refined and plugged into SWComponentsProtoTypes. Blueprintable elements have no impact on the AUTOSAR RTE level (impact covered by derive prototype elements) There are different types of Blueprintable elements in the Application Interface domain. They are collected into different packages categorized as BLUEPRINT: DataConstrs ApplicationDataTypes CompuMethods PortInterfaces PortPrototypeBlueprints Keywords Collections In the scope of Application Interfaces, the general rules for compliance of blueprint and blueprinted elements are strictly followed [9]. Derived elements from blueprint are allowed to change longName, desc (description) and introduction attributes, while a specific attribute, called namePattern is specified if the shortName, respectively a symbol, is not fixed but intended to be defined when objects are derived from blueprints (e.g. in series projects). The shortName of the derived obiects shall follow the pattern defined in namePattern attribute. The complete syntax used by the namePattern attribute is defined in [9] and it will not be reported here in detail. Nevertheless since this syntax nearly leads to any possible solution for building shortNames, it’s strongly suggested that it‘s used to stick with rules for shortName construction, already defined for each kind of elements in this document. Even if no obligatory pattern is defined and the value of the attribute is ‘anyName’, the following use cases and relative syntax usage are strongly recommended: Use case 1: element used once (one derived element): {blueprintName} Use case 2: element used twice or more (two or more derived elements): {blueprintName}({ 0 1 })0..n where {blueprintName} represents the shortName / shortLabel / symbol of the applied blueprint. Special attention will be payed now to PortPrototypeBlueprint elements since the following considerations are also valid for other blueprintable elements in general (Please check [9] for more specific details). 6.5.18 PortPrototypeBlueprint (PORT-PROTOTYPE-BLUEPRINT) For the scope of this document a PortPrototypeBlueprint has the following characteristics: 51 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 It is an ARElement and does therefore not require any element other than an ARPackage as context. It is therefore not necessary to involve “auxiliary” model elements into the definition of a standardized “application interface” for the mere purpose of conforming to the AUTOSAR meta-model. The structure of the created PortPrototype is indistinguishable from a PortPrototype created without taking a PortPrototypeBlueprint as a blueprint. A PortPrototypeBlueprint can be taken as the blueprint for as many PortPrototypes as required. It can only be used for the standardization of “application interfaces”. A PortPrototypeBlueprint does not play any role in the formal description of any SwComponentType or related model artifacts. To be sure, the existence of a PortPrototypeBlueprint has no impact on the AUTOSAR RTE. Derived PortPrototypes may have more attributes than the PortPrototypeBlueprint The attributes of derived PortPrototypes are copied from the PortPrototypeBlueprint with one exception, the attribute namePattern that may not be copied. The attribute namePattern represents the pattern which shall be used to build the shortName of the derived elements (in this case PortPrototypes). This allows to change the shortName of a PortPrototype derived from a PortPrototypeBlueprint according to predefined rules. [TR_SWNR_00037] Indication of provided/required operation or data ⌈ The PortPrototypeBlueprint shall indicate the operation or data that is provided/required by the port.⌋ ( RS_SWMG_00006 , RS_SWMG_00054) 52 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - SW-C and System Modeling Guide AUTOSAR Release 4.2.2 6.5.19 Keywords Keywords, which represent a set of basic elements for short names construction, are collected into one package, named KeywordSets_Blueprint, and categorized as BLUEPRINT in order to support the addition of long names and documentation in different languages. Rules for using keywords and their abbreviated names (in the role of abbrName attribute) in shortnames construction are described in chapter 6.3.1. Example : PortPrototypeBlueprints_Blueprint BLUEPRINT PortInterfaces false false false /AUTOSAR/AISpecification/PortInterfaces_Blueprint . . . . . . DrvrProf Driver Profile Status of current selected personalization profile from profile manager. It is a common profile selectable from transponder, remote key, keyless access, Human Machine Interface (HMI),... ProfPenSt1 53 of 53 Document ID 207: AUTOSAR_TR_SWCModelingGuide - AUTOSAR Confidential - KeywordSets_Blueprint BLUEPRINT KeywordList AUTOSAR Keywords and Keywords Abbreviations . . . Idx0 0 Index 0. This keyword is used to express the number zero in form of an index 0 Index Abs Abs antilock braking system Abs Mean-Environment-Device . . Abslt Absolute Absolute value Abslt Condition-Qualifier
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.5 Linearized : No Page Count : 53 Language : de-DE Tagged PDF : Yes Title : SW-C and System Modeling Guide Author : AUTOSAR Subject : AUTOSAR Keywords : Release, 4.2 Creator : Microsoft® Word 2010 Create Date : 2015:07:23 12:00:06+02:00 Modify Date : 2015:07:23 12:00:06+02:00 Producer : Microsoft® Word 2010EXIF Metadata provided by EXIF.tools