団体規格です。
業務で利用する場合には、会員になることを条件にしています。
2002年から20年経ち、当初の狙いの段階に近づいてきました。
MATLABでモデルさえ記述すれば、あとは自動生成だけでソフトが完成するところまで、あと一歩です。
Ethernet, UNIXが生まれて20年で大衆化したのと同じように考えると分かりやすいでしょう。
AUTOSARの上で動く、クラウド対応のミドルウェアが出て、開発も運用もクラウドになれば、一気にAUTOSARは大衆化するでしょう。
AUTOSAR Abstract Platformへの道 R22-11
2023年4月URL変更
この項は2023年4月21日、AUTOSARの文書のURLが変更になった。
/classic/22-11/
が
/R22-11/CP/
過去記事で、URLでエラーが出たら書き換えてみてください。
/adaptive/22-11/
は
/R22-11/AP/
/foundation/22-11/
は
/R22-11/FO/
です。
2023年11月URL変更
2023年11月にもAUTOSAR文書のURLが変更になっている。
/user_upload/standards/classic/21-11/
を
/standards/R21-11/CP/
などに書き換えてください。
/user_upload/standards/adaptive/21-11/
を
/standards/R21-11/AP/
/user_upload/standards/foundation/21-11/
を
/standards/R21-11/FO/
お手数をおかけします。
１年に２度URLを変更するなんて、新しい記事が書ける。とても嬉しい。
一覧
AUTOSAR R22-11 Qiita記事一覧 20230421 。
この記事の表題の最後に「20230421」を加えます。
<この項は書きかけです。順次追記します。>
AUTOSARが、2022年の版、R22-11を公開しました。
R21-11
R20-11
R19-11
文書は検索してダウンロードできます。
R20-11,R21-11, R22-11の３年分だけになりました。
公開行事の模様は
AUTOSAR R22-11 Release Event 20221208
Classic Platform Release Overview, AUTOSAR No.0 ,R22-11, CP, 20230421
Foundation Release Overview, AUTOSAR, 781, R22-11, FO, 20230421
Adaptive Platform Release Overview, AUTOSAR 782, R22-11, AP, 20230421
要求仕様対応(Requirement and Specification)
Abstract Platformとの関係
Template, TypeはAbstract Platformで統一的に定義するとよい。
Template, Typeで、複数の文書を統合するとよい。
<この項は書きかけです。順次追記します。>
文書変更(Document Change)
• Added the obsolete statement
用語(terms)
| Term | Description |
|---|---|
| Real-time application (RTA) | A real-time application is a program that guarantees response within defined time constraints. The latency must be less than a defined value, usually measured in seconds or milliseconds. Whether or not a given application program qualifies as an RTA depends on the worst-case execution time (WCET) - themaximum length of time a defined task requires on a given hardware platform. |
| MISRA | Motor Industry Software Reliability Association. |
| HIC++ | High Integrity C++ Coding Standard. |
| cvalue expression | An expression that should not undergo further conversions, either implicitly or explicitly, is called a cvalue expression. |
| Ownership | Ownership of a resource means that the resource’s lifetime is fully managed by the single class instance or tied with the class instance lifetime. See also: chapter 6.18.5 |
| One definition rule | The rule states that: There shall be one and only one definition of any variable, function, class type, enumeration type, or template in a translation unit. Some of these may have multiple declarations, but only one definition is allowed. There shall be one and only one definition of every noninline function or variable that is odr-used in the entire program. An inline function definition is required in every translation unit where it is odr-used. There shall be one and only one definition of a class in any translation unit where the class is used in a way that requires it to be complete. There can be more than one definition of any class, enumeration type, inline function with external linkage, class template, non-static function template, static data member of a class template, member function of a class template, partial template specialization in a program, as long as all of the following is true: – each definition consists of the same sequence of tokens (typically, appears in the same header file) – name lookup from within each definition finds the same entities (after overload-resolution), except that constants with internal or no linkage may refer to different objects as long as they are not ODR-used and have the same values in every definition. – overloaded operators, including conversion, allocation, and deallocation functions refer to the same function from each definition (unless referring to one defined within the definition) – the language linkage is the same (e.g. the include file isn’t inside an extern “C” block) – the three rules above apply to every default argument used in each definition – if the definition is for a class with an implicitlydeclared constructor, every translation unit where it is odr-used must call the same constructor for the base and members – if the definition is for a template, then all these requirements apply to both names at the point of definition and dependent names at the point of instantiation If all these requirements are satisfied, the program behaves as if there is only one definition in the entire program. Otherwise, the behavior is undefined. |
| ODR-use | An object is odr-used if its address is taken, or a reference is bound to it. A function is odr-used if a function call to it is made or its address is taken. |
| POD Type | POD (Plain Old Data) type is the type that is compatible with types used in the C programming language, can be manipulated using C library functions, and can be exchanged with C libraries directly in its binary form. |
| Trivially Copyable Class | A class (C++ Language Standard [3], chapter 9): where each copy constructor, move constructor, copy assignment operator, move assigment operator is either deleted or trivial that has at least one non-deleted copy constructor, move constructor, copy assignment operator, or move assignment operator, and that has a trivial, non-deleted destructor |
| Standard-Layout Class | A class that (C++ Language Standard [3], chapter 9): has no non-static data members of type non-standardlayout class (or array of such types) or reference has no virtual functions and no virtual base classes has the same access control for all non-static data members has no non-standard-layout base classes has at most one base class subobject of any given type has all non-static data members and bit-fields in the class and its base classes first declared in the same class has no element of the set M(X) of types as a base class where M(X) is defined as follows: – If X is a non-union class type, the set M(X) is empty if X has no (possibly inherited) non-static data members; otherwise, it consists of the type of the first non-static data member of X (where said member may be an anonymous union), X0, and the elements of M(X0). – If X is a union type, the set M(X) is the union of all M(Ui) and the set containing all Ui, where each Ui is the type of the i-th non-static data member of X. – If X is a non-class type, the set M(X) is empty. |
| Dataflow Anomaly | The state of a variable at a point in a program can be described using the following terms: Undefined (U): The value of the variable is indeterminate. Referenced (R): The variable is used in some way (e.g. in an expression). Defined (D): The variable is explicitly initialized or assigned a value. Given the above, the following dataflow anomalies can be defined: UR dataflow anomaly: Variable not assigned a value before the specified use (this may result in undefined behavior). DU dataflow anomaly: Variable is assigned a value that is never subsequently used. DD dataflow anomaly: Variable is assigned a value twice with no intermediate use. |
| Dead Code | Dead code (also known as redundant code) consists of evaluated expressions whose removal would not affect the output program. |
| Unreachable Code | Unreachable code is code to which there is no syntactic (control flow) path, e.g. a function which is never called, either directly or indirectly. |
| Diamond Problem | The “diamond problem” is an ambiguity that arises when two classes B and C inherit from A, and class D inherits from both B and C. If there is a method provided by class A, that is overriden in both B and C and D does not override it, then there is an ambiguity which version of the method does D actually inherit. See: Wikipedia.org for more details. |
| Interface class | An interface class is a class which has following properties: if there are any, all member functions are public pure virtual if there are any, all data members are public static constexpr |
| Extended precision format | The IEEE Standard for Floating-Point Arithmetic (IEEE 754) specifies extended precision formats, that are recommended for allowing a greater precision format than that provided by the basic formats. For an extended format the exponent range must be as great as that of the next wider basic format. For instance, 64-bit extended precision binary number must have an “exponent max” of at least 16383, which is equal to “exponent max” of 128- bit binary floating-point. The 80-bit extended format meets this requirement. |
| Fundamental types | C++ built-in types defined in C++ Language Standard [3] in chapter 3.9.1, e.g. char, signed char, unsigned char, int, long long int, wchar_t, bool, float, double, void, std::nullptr_t, etc. |
| Scalar types | The following types are scalar types: integral types floating point types pointers and pointers to members enumerations std::nullptr_t |
| glvalue | A glvalue is an expression whose evaluation determines the identity of an object, bit-field, or function. |
| xvalue | An xvalue refers to an object, usually near the end of its lifetime, so that its resources may be moved. |
| prvalue | A prvalue is an expression whose evaluation initializes an object or a bit-field, or computes the value of the operand of an operator. |
| rvalue | An rvalue is an xvalue or a prvalue. |
| lvalue | An lvalue is a glvalue that is not an xvalue. |
| Implicitly-defined default constructor | Implicitly-defined default constructor calls default constructors of its base classes and non-static data members. It has exactly the same effect as a user-defined constructor with empty body and empty initializer list. |
| Implicitly-defined copy constructor | Implicitly-defined copy constructor of a class type (class or struct) performs full member-wise copy of the object’s bases and nonstatic data members, in their initialization order, using direct initialization. |
| Implicitly-defined move constructor | Implicitly-defined move constructor of a class type (class or struct) performs full member-wise move of the object’s bases and non-static members, in their initialization order, using direct initialization with an xvalue argument. |
| Implicitly-defined copy assignment operator | Implicitly-defined copy assignment operator of a class type (class or struct) performs full member-wise copy assignment of the object’s bases and non-static data members, in their initialization order, using built-in assignment for the scalars and copy assignment operator for class types. |
| Implicitly-defined move assignment operator | Implicitly-defined move assignment operator of a class type (class or struct) performs full member-wise move assignment of the object’s direct bases and immediate non-static data members, in their initialization order, using built-in assignment for the scalars, member-wise move-assignment for arrays, and move assignment operator for class types (called non-virtually). |
| Implicitly-defined destructor | Implicitly-defined destructor has an empty body. After the body of the destructor is executed, the destructors for all non-static nonvariant data members of the class are called, in reverse order of declaration. Then it calls destructors of all direct non-virtual base classes, in reverse order of construction, and then it calls the destructors of all virtual bases. |
| Is-a relationship | Subsumption relationship between types. If one class B is a subclass of another class A (i.e. B is a more specialized concept than A), then B class specification implies A class specification and a B class object can be used for any expression that requires an A class object. |
| Has-a relationship | Composition relationship where one object is a part or member of another object with respect to the rules of ownership. |
| Single point of exit | Approach background: IEC 61508 [19], as one of methods for providing modular approach. ISO26262 part 6 [5] with the requirement for ASIL A-D. MISRA-C++ 2008 with the rule M6-6-5. AUTOSAR Coding Guidelines consider that the only reason for such an approach is improving robustness of resource handling, e.g. ensuring that resources are properly released in case of an early exit from the function. However, it is fully ensured by other rules existing in the document that: enforce usage of smart pointers and memory management objects for expressing lifetime semantics (A18-5-2) enforce allocate local objects on stack (A18-5-8) recommend usage of RAII (A15-1-4, A18-5-2) Single point of exit is considered to decrease code readability and will not bring any additional benefits for improving coding standards, thus it is not enforced by the AUTOSAR Coding Guidelines. |
英日
日本語は仮訳
| no. | count | word | 日本語 |
|---|---|---|---|
| 1 | 5014 | a | 一つの |
| 2 | 3682 | the | その |
| 3 | 2736 | of | の |
| 4 | 2035 | std | standard(短縮名） |
| 5 | 2015 | c | c |
| 6 | 1699 | to | に |
| 7 | 1610 | and | と |
| 8 | 1591 | in | の |
| 9 | 1460 | not | ない |
| 10 | 1425 | be | です |
| 11 | 1370 | is | です |
| 12 | 1261 | guidelines | 指針 |
| 13 | 1240 | for | にとって |
| 14 | 1174 | compliant | 準拠 |
| 15 | 1143 | rule | 規則 |
| 16 | 1140 | autosar | AUTomotive Open System Architecture(短縮名) |
| 17 | 1022 | _t | _t |
| 18 | 966 | use | 使用する |
| 19 | 911 | shall | しなければならない |
| 20 | 905 | int | integer（短縮名） |
| 21 | 807 | non | 非（接頭辞） |
| 22 | 803 | m | m |
| 23 | 780 | class | 級 |
| 24 | 749 | id | identifier, 識別子(短縮名） |
| 25 | 739 | an | と |
| 26 | 714 | differences | 違い |
| 27 | 713 | or | また |
| 28 | 704 | that | それ |
| 29 | 682 | no | いいえ |
| 30 | 662 | type | 型 |
| 31 | 633 | language | 言語 |
| 32 | 631 | required | 必要 |
| 33 | 579 | function | 働き |
| 34 | 578 | related | 関連している |
| 35 | 576 | document | 資料 |
| 36 | 558 | f | f |
| 37 | 556 | see | 見る |
| 38 | 554 | safety | 安全性 |
| 39 | 554 | void | 空所 |
| 40 | 545 | small | 小さい |
| 41 | 544 | implementation | 実装 |
| 42 | 543 | release | 公開 |
| 43 | 524 | critical | 致命的 |
| 44 | 523 | used | 使用済み |
| 45 | 521 | systems | 系 |
| 46 | 510 | ap | adaptive platform(短縮名) |
| 47 | 509 | autosar_rs_cpp | autosar_rs_cpp |
| 48 | 509 | confidential | 信頼 |
| 49 | 495 | if | もしも |
| 50 | 494 | include | 含む |
| 51 | 487 | const | constant(短縮名） |
| 52 | 482 | b | b |
| 53 | 459 | except | それ外 |
| 54 | 459 | with | と |
| 55 | 456 | by | により |
| 56 | 451 | x | x |
| 57 | 448 | it | それ |
| 58 | 435 | this | これ |
| 59 | 431 | are | それは |
| 60 | 411 | exception | 例外 |
| 61 | 407 | t | t |
| 62 | 401 | automated | 自動化 |
| 63 | 397 | as | なので |
| 64 | 392 | return | 戻る |
| 65 | 374 | cpp | c plus plus(短縮名） |
| 66 | 371 | e | e |
| 67 | 362 | also | また |
| 68 | 360 | operator | 操作者 |
| 69 | 340 | object | 物体 |
| 70 | 337 | only | それだけ |
| 71 | 327 | public | 公衆 |
| 72 | 307 | av | av |
| 73 | 302 | example | 例 |
| 74 | 298 | from | から |
| 75 | 289 | functions | 関数 |
| 76 | 285 | i | 私 |
| 77 | 280 | uint | unsigned integer(短縮名） |
| 78 | 278 | do | 行う |
| 79 | 278 | rejected | 拒否した |
| 80 | 276 | rationale | 理論的根拠 |
| 81 | 275 | will | 意思 |
| 82 | 273 | misra | Motor Industry Software Reliability Association(短縮名） |
| 83 | 263 | all | すべて |
| 84 | 263 | v | v |
| 85 | 260 | standard | 標準 |
| 86 | 259 | error | 誤り |
| 87 | 255 | pointer | 指示子 |
| 88 | 255 | z | z |
| 89 | 251 | name | 名前 |
| 90 | 246 | defined | 定義済み |
| 91 | 239 | on | の上 |
| 92 | 238 | default | 既定値 |
| 93 | 232 | using | 使って |
| 94 | 230 | code | 符号 |
| 95 | 225 | template | 雛形 |
| 96 | 222 | memory | 記憶装置 |
| 97 | 217 | d | d |
| 98 | 216 | new | 新着 |
| 99 | 216 | should | したほうがいい |
| 100 | 214 | can | できる |
参考(reference)
bibliographyとして一覧を示している。
Glossary も 入れましょう。
https://www.autosar.org/fileadmin/standards/R22-11/FO/AUTOSAR_TR_Glossary.pdf
CAN(cont
ISO/IEC 14882:2003, The C++ Standard Incorporating Technical Corrigendum 1, International Organization for Standardization, 2003.
ISO/IEC 14882:2011, ISO International Standard ISO/IEC 14882:2011(E) - Programming
Language C++, International Organization of Standardization, 2011.
ISO/IEC 14882:2014, ISO International Standard ISO/IEC 14882:2014(E) - Programming
Language C++, International Organization for Standardization, 2016.
ISO 26262-6, Road vehicles - Functional safety - Part 6: Product development at the software level, International Organization for Standardization, 2011.
ISO 26262-6, Road vehicles - Functional safety - Part 6: Product development at the software level, International Organization for Standardization, 2011.
ISO 26262-8, Road vehicles - Functional safety - Part 8: Supporting processes,
International Organization for Standardization, 2011.
MISRA C++:2008 Guidelines for the use of the C++ language in critical systems, The
Motor Industry Software Reliability Association, 2008.
Joint Strike Fighter Air Vehicle C++ Coding Standards for the System Development and Demonstration Program, Document Number 2RDU00001 Rev C, Lockheed
Martin Corporation, 2005.
High Integrity C++ Coding Standard Version 4.0, Programming Research Ltd, 2013.
Software Engineering Institute CERT C++ Coding Standard, Software Engineering
Institute Division at Carnegie Mellon University, 2016.
Bjarne Stroustrup, Herb Sutter, C++ Core Guidelines, 2017.
Google C++ Style Guide, Google, 2017.
Scott Meyers, Effective Modern C++, ISBN: 978-1-491-90399-5, O’Reilly, 2015.
Bjarne Stroustrup, The C++ Programming Language, Fourth Edition, ISBN: 978-
0-321-56384-2, Addison-Wesley, 2013.
Joshua Bloch, Effective Java, Second Edition, ISBN: 978-0321356680, AddisonWesley, 2008
cppreference.com, online reference for the C and C++ languages and standard
libraries, 2017
stackoverflow.com, community of programmers, 2017
open-std.org, site holding a number of web pages for groups producing open
standards, 2017
IEC 61508-3, Functional safety of electrical/electronic/programmable electronic
safety-related systems – Annex C, Overview of techniques and measures for
achieving software safety integrity, International Electrotechnical Commission,
2010.
全く同じ行がある。その後、３年治っていない。
ISO 26262-6, Road vehicles - Functional safety - Part 6: Product development at the software level, International Organization for Standardization, 2011.
ならびから行くと、-7の可能性はある。
ISO 26262-7:2011
Road vehicles — Functional safety — Part 7: Production and operation
その後継の規格が出ている。言及がないのはなぜかわかっていない。
ISO 26262-6:2018
Road vehicles — Functional safety — Part 6: Product development at the software level
ISO 26262-8:2018
Road vehicles — Functional safety — Part 8: Supporting processes
IEC TS 61508-3-1:2016
Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 3-1: Software requirements - Reuse of pre-existing software elements to implement all or part of a safety function
関連文書(Related document)
AUTOSAR Abstract Platformへの道 R22-11
自動車 記事 １００
Basic principles, ボッシュ自動車handbook(英語)11版まとめ<2>
JAXA/IPA クリティカルソフトウェアワークショップ WOCS言語関連発表(改定版)
CAN(controller area network)
「はじめての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の仕組みと設計のために
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
文書履歴(document history)
ver. 0.01 初稿 20230715
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.