Standardization Template, AUTOSAR 22-11, FO, No.535
AUTOSARは、ISO、IEC、ITUと情報交換契約を結んでいません。
AUTOSAR文書には、ISO、IEC,ITU記述を全文引用することはできません。
WTO/TBT協定に基づき、国際的な調達は国際規格との差異を記述することにより文化依存しない仕様を目指します。
ISO、IEC、ITU文書を合わせて読むと技術内容は理解できます。
CAN、OSEK/VDX OS、DIAGは、ISO定義を先に確認しましょう。
OSEK COM、OSEK NMなどはISOの規定から基本的な部分で定義を変えています。
変更している部分を仕様等で明記するか、ISOを改定するとよいでしょう。
AUTOSARの参考文献欄の改定が進んでいません。
Glossary用語定義の網羅性が低いです。
本文を読む前に確認するとよいかもしれません。
本文を読んでから確認してもよいかもしれません。
AUTOSARが、2022年の版、R22-11公開しました。公開行事の模様は
AUTOSAR R22-11 Release Event 20221208
下記URL順次確認中です。
間違っていたら、いいね を押していただいて、コメント欄にご報告くださると幸いです。
編集リクエストが、構造的な変更をしている最中に、構造的な編集リクエストをしていただくと、
何をどう直したらいいかわからなくなってしまいます。自動修復ツールがつくれていません。ごめんなさい。
文書は検索してダウンロードすることができます。
クラウドサービスにありがちな、あるのにないかのような検索結果が出ることがあります。
equirement and Specification)
一覧
AUTOSAR R22-11 Foundation(Abstract Platform) 一覧はこちら。
Foundation Release Overview, No.781, FO, AUTOSAR 22-11(2)
AUTOSAR R22-11 マラソン
Qiitaの記事の一覧は作成中です。
AUTOSAR R22-11 一覧（２）
Abstract Platformとの関係
Template, TypeはAbstract Platformで統一的に定義するとよい。
Template, Typeで、複数の文書を統合するとよい。
<この項は書きかけです。順次追記します。>
文書変更(Document Change)
• Advisory item
• Sentence pattern
• Extension of namePattern for platform
用語(terms)
| Term | Description |
|---|---|
| Artifact | This is a Work Product Definition that provides a description and definition for tangible work product types. Artifacts may be composed of other artifacts ([22]). At a high level, an artifact is represented as a single conceptual file. |
| AUTOSAR Tool | This is a software tool which supports one or more tasks defined as AUTOSAR tasks in the methodology. Depending on the supported tasks, an AUTOSAR tool can act as an authoring tool, a converter tool, a processor tool or as a combination of those (see separate definitions). |
| AUTOSAR Authoring Tool | An AUTOSAR Tool used to create and modify AUTOSAR XML Descriptions. Example: System Description Editor. |
| AUTOSAR Converter Tool | An AUTOSAR Tool used to create AUTOSAR XML files by converting information from other AUTOSAR XML files. Example: ECU Flattener |
| AUTOSAR Definition | This is the definition of parameters which can have values. One could say that the parameter values are Instances of the definitions. But in the meta model hierarchy of AUTOSAR, definitions are also instances of the meta model and therefore considered as a description. Examples for AUTOSAR definitions are: EcucParameterDef, PostBuildVariantCriterion, SwSystemconst. |
| AUTOSAR XML Description | In AUTOSAR this means "filled Template". In fact an AUTOSAR XML description is the XML representation of an AUTOSAR model. The AUTOSAR XML description can consist of several files. Each individual file represents an AUTOSAR partial model and shall validate successfully against the AUTOSAR XML schema. |
| AUTOSAR Meta-Model | This is an UML2.0 model that defines the language for describing AUTOSAR systems. The AUTOSAR meta-model is an UML representation of the AUTOSAR templates. UML2.0 class diagrams are used to describe the attributes and their interrelationships. Stereotypes, UML tags and OCL expressions (object constraint language) are used for defining specific semantics and constraints. |
| AUTOSAR Meta-Model Tool | The AUTOSAR Meta-Model Tool is the tool that generates different views (class tables, list of constraints, diagrams, XML Schema etc.) on the AUTOSAR meta-model. |
| AUTOSAR Model | This is a representation of an AUTOSAR product. The AUTOSAR model represents aspects suitable to the intended use according to the AUTOSAR methodology. Strictly speaking, this is an instance of the AUTOSAR meta-model. The information contained in the AUTOSAR model can be anything that is representable according to the AUTOSAR meta-model. |
| AUTOSAR Partial Model | In AUTOSAR, the possible partitioning of models is marked in the meta-model by atpSplitable. One partial model is represented in an AUTOSAR XML description by one file. The partial model does not need to fulfill all semantic constraints applicable to an AUTOSAR model. |
| AUTOSAR Processor Tool | An AUTOSAR Tool used to create non-AUTOSAR files by processing information from AUTOSAR XML files. Example: RTE Generator |
| AUTOSAR Specification Element | An AUTOSAR Specification Element is a named element that is part of an AUTOSAR specification. Examples: requirement, constraint, specification item, class or attribute in the meta model, methodology, deliverable, methodology activity, model element, bsw module etc. |
| AUTOSAR Template | The term "Template" is used in AUTOSAR to describe the format different kinds of descriptions. The term template comes from the idea, that AUTOSAR defines a kind of form which shall be filled out in order to describe a model. The filled form is then called the description. In fact the AUTOSAR templates are now defined as a meta-model. |
| AUTOSAR Validation Tool | A specialized AUTOSAR Tool which is able to check an AUTOSAR model against the rules defined by a profile. |
| AUTOSAR XML Schema | This is a W3C XML schema that defines the language for exchanging AUTOSAR models. This Schema is derived from the AUTOSAR meta-model. The AUTOSAR XML Schema defines the AUTOSAR data exchange format. |
| Blueprint | This is a model from which other models can be derived by copy and refinement. Note that in contrast to meta model resp. types, this process is not an instantiation. |
| Instance | Generally this is a particular exemplar of a model or of a type. |
| Life Cycle | Life Cycle is the course of development/evolutionary stages of a model element during its life time. |
| Meta-Model | This defines the building blocks of a model. In that sense, a Meta-Model represents the language for building models. |
| Meta-Data | This includes pertinent information about data, including information about the authorship, versioning, access-rights, timestamps etc. |
| Model | A Model is an simplified representation of reality. The model represents the aspects suitable for an intended purpose. |
| Partial Model | This is a part of a model which is intended to be persisted in one particular artifact. |
| Pattern in GST | This is an approach to simplify the definition of the meta model by applying a model transformation. This transformation creates an enhanced model out of an annotated model. |
| Profile Authoring Support Data | Data that is used for efficient authoring of a profile. E.g. list of referable constraints, meta-classes, meta-attributes or other reusable model assets (blueprints) |
| Profile Authoring Tool | A specialized AUTOSAR Tool which focuses on the authoring of profiles for data exchange points. It e.g. provides support for the creation of profiles from scratch, modification of existing profiles or composition of existing profiles. |
| Profile Compatibility Checker Tool | A specialized AUTOSAR Tool which focuses on checking the compatibility of profiles for data exchange. Note that this compatibility check includes manual compatibility checks by engineers and automated assistance using more formal algorithms. |
| Profile Consistency Checker Tool | A specialized AUTOSAR Tool which focuses on checking the consistency of profiles. |
| Property | A property is a structural feature of an object. As an example a “connector” has the properties “receive port” and “send port” Properties are made variant by the atpVariation. |
| Prototype | This is the implementation of a role of a type within the definition of another type. In other words a type may contain Prototypes that in turn are typed by "Types". Each one of these prototypes becomes an instance when this type is instantiated. |
| Type | A type provides features that can appear in various roles of this type. |
| Value | This is a particular value assigned to a “Definition”. |
| Variability | Variability of a system is its quality to describe a set of variants. These variants are characterized by variant specific property settings and / or selections. As an example, such a system property selection manifests itself in a particular “receive port” for a connection. This is implemented using the atpVariation. |
| Variant | A system variant is a concrete realization of a system, so that all its properties have been set respectively selected. The software system has no variability anymore with respect to the binding time. This is implemented using EvaluatedVariantSet. |
| Variation Binding | A variant is the result of a variation binding process that resolves the variability of the system by assigning particular values/selections to all the system’s properties. This is implemented by VariationPoint. |
| Variation Binding Time | The variation binding time determines the step in the methodology at which the variability given by a set of variable properties is resolved. This is implemented by vh.LatestBindingtime at the related properties. |
| Variation Definition Time | The variation definition time determines the step in the methodology at which the variation points are defined. |
| Variation Point | A variation point indicates that a property is subject to variation. Furthermore, it is associated with a condition and a binding time which define the system context for the selection / setting of a concrete variant. This is implemented by VariationPoint. |
英日
日本語は仮訳
| count | word | 日本語 |
|---|---|---|
| 2936 | the | その |
| 2140 | of | の |
| 1039 | in | 中に |
| 928 | a | 一つの |
| 907 | is | です |
| 906 | to | に |
| 805 | autosar | autosar |
| 749 | tps_stdt_ | tps_stdt_ |
| 717 | data | 与件 |
| 701 | this | これ |
| 643 | template | 雛形 |
| 631 | name | 名前 |
| 555 | class | 級 |
| 531 | c | c |
| 531 | for | にとって |
| 523 | atp | atp |
| 489 | short | 短い |
| 484 | be | です |
| 462 | type | 型 |
| 461 | and | と |
| 445 | attribute | 属性 |
| 426 | that | それ |
| 414 | element | 要素 |
| 400 | port | 港 |
| 384 | note | 覚書 |
| 373 | blue | 青 |
| 362 | time | 時間 |
| 345 | prototype | ひながた |
| 345 | rs_stdt_ | rs_stdt_ |
| 341 | tags | 札 |
| 340 | r | r |
| 329 | an | 一つの |
| 327 | shall | しなければならない |
| 326 | standardization | 標準化 |
| 323 | document | 資料 |
| 320 | by | に |
| 315 | are | です |
| 311 | point | 点 |
| 290 | blueprint | 設計図 |
| 279 | not | いいえ |
| 278 | ar | AUTOSAR(短縮名) |
| 278 | id | id |
| 269 | xml | xml |
| 254 | package | 小包 |
| 253 | fo | foundation(短縮名) |
| 250 | or | または |
| 248 | autosar_tps_standardization | autosar_tps_standardization |
| 242 | if | もし |
| 233 | table | 表 |
| 231 | specification | 仕様 |
| 228 | aggr | aggregation(短縮名) |
| 226 | l | l |
| 224 | meta | 超 |
| 223 | object | 物体 |
| 222 | value | 価値 |
| 221 | with | と |
| 218 | interface | 界面 |
| 210 | referrable | 参照可能 |
| 209 | d | d |
| 209 | scope | 範囲 |
| 208 | elements | 要素 |
| 208 | types | 型 |
| 203 | as | なので |
| 202 | multiplicity | 多様性 |
| 202 | ref | reference(短縮名) |
| 198 | variation | 変化 |
| 196 | m | m |
| 192 | tailoring | 仕立て |
| 183 | base | 基づく |
| 183 | module | 部品 |
| 181 | sw | software(短縮名) |
| 178 | it | それ |
| 178 | represents | を表す |
| 178 | which | どの |
| 174 | sequence | 順序 |
| 173 | binding | 縛り |
| 173 | offset | 補正 |
| 172 | kind | 親切 |
| 172 | model | 模型 |
| 171 | constraints | 制約 |
| 168 | atpvariation | atpvariation |
| 167 | description | 説明 |
| 166 | stereo | 立体の |
| 164 | TRUE | 真 |
| 163 | can | できる |
| 160 | identifiable | 識別可能 |
| 156 | structure | 構造 |
| 154 | component | 成分 |
| 154 | 印刷 | |
| 152 | used | 使った |
| 151 | reference | 参照 |
| 150 | templates | ひながた |
| 147 | mult | 複数の |
| 146 | mapping | 対応付け |
| 142 | ecu | ecu |
| 142 | on | の上 |
| 142 | set | 設定する |
| 142 | variable | 変数 |
| 139 | latest | 最新 |
| 137 | exchange | 交換 |
参考(reference)
Glossary も 参考に入れましょう。
https://www.autosar.org/fileadmin/standards/R22-11/FO/AUTOSAR_TR_Glossary.pdf
[1] Software Component Template
AUTOSAR_TPS_SoftwareComponentTemplate
[2] Requirements on Standardization Template
AUTOSAR_RS_StandardizationTemplate
[3] Predefined Names in AUTOSAR
AUTOSAR_TR_PredefinedNames
[4] Specification of Safety Extensions
AUTOSAR_TPS_SafetyExtensions
[5] List of Basic Software Modules
AUTOSAR_TR_BSWModuleList
[6] Generic Structure Template
AUTOSAR_TPS_GenericStructureTemplate
[7] XML Path language (XPath)
http://www.w3.org/TR/xpath/
[8] ANTLR parser generator V3
[9] Specification of ECU Configuration
AUTOSAR_TPS_ECUConfiguration
[10] Unique Names for Documentation, Measurement and Calibration: Modeling and Naming Aspects including Automatic Generation
AUTOSAR_TR_AIMeasurementCalibrationDiagnostics
[11] XML Specification of Application Interfaces
AUTOSAR_MOD_AISpecification
[12] Specification of Timing Extensions
AUTOSAR_TPS_TimingExtensions
[13] Explanation of Application Interfaces of the Powertrain Engine Domain
AUTOSAR_EXP_AIPowertrain
[14] SW-C and System Modeling Guide
AUTOSAR_TR_SWCModelingGuide
[15] Specification of Platform Types
AUTOSAR_SWS_PlatformTypes
[16] Specification of CRC Routines
AUTOSAR_SWS_CRCLibrary
[17] Methodology for Classic Platform
AUTOSAR_TR_Methodology
[18] Meta Model
AUTOSAR_MMOD_MetaModel
[19] Collection of constraints on AUTOSAR M1 models
AUTOSAR_TR_AutosarModelConstraints
[20] AUTOSAR XML Schema Production Rules
AUTOSAR_TPS_XMLSchemaProductionRules
[21] Meta Model-generated XML Schema
AUTOSAR_MMOD_XMLSchema
[22] Software Process Engineering Meta-Model Specification
http://www.omg.org/spec/SPEM/2.0/
関連文書(Related document)
AUTOSAR Abstract Platformへの道（詳細編）
2023年1月 記事数一覧
年末100記事を30点に仕上げる。
2023 書き初め
「はじめてのCAN/CANFD 」 ベクタージャパン ＜エンジニア夏休み企画>【読書感想文】
三方良し Udemy 車載LAN入門講座 CAN通信編
詳解 車載ネットワーク CAN, CAN FD, LIN, CXPI, Ethernetの仕組みと設計のために(1) 著者 ＜エンジニア夏休み企画 読書感想文＞
詳解 車載ネットワーク CAN, CAN FD, LIN, CXPI, Ethernetの仕組みと設計のために(2)参考文献 ＜エンジニア夏休み企画>【読書感想文】
詳解 車載ネットワーク CAN、CAN FD、LIN、CXPI、Ethernetの仕組みと設計のために
AUTOSAR Abstract Platform User Group Weekly Report(1) 2022.1.8
AUTOSAR Abstract Platform User Group Weekly Report(2) 2022.1.15
202304 URL更新
Standardization Template, AUTOSAR 535, R22-11, FO, 20230421
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
文書履歴(document history)
ver. 0.01 初稿 記 20230123
ver. 0.02 ありがとう追記 20230701
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.