Glossary AUTOSAR 55, R23-11 FO
https://qiita.com/kaizen_nagoya/items/f01ad357d9bbd0b80aad

英語がわかりにくいとの意見から、日本語の仮訳をつけて、英語のわかり易い候補を記載します。

<この項は書きかけです。順次追記します。>
This article is not completed. I will add some words in order.

＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
This article is an individual impression based on the individual's experience. It has nothing to do with the organization or business to which I currently belong.

仮訳方針

AUTOSAR(AUTomotive Open System Architecture)、ARA(AUTOSAR Runtime for Adaptive Application)、OBD(On-Board Diagnostic）はそのまま英語表記とする。
それ以外は、原則カタカナ語以外に訳す。
softwar(軟件)、service(奉仕)は、あまり受けがよくない。現在の版ではカタカナ語にしている。他の日本語表現があれば１文字または２文字であればお勧めをcomment欄にお書きください。
英語をカタカナ語に変換すると、一つのカタカナ語に対して、複数の英語が対応することになることがある。意味が直感的に捉えにくいか、誤解をすることがある。例えば、ライトはright, light, liteなど。そこで、意味を考えてもらえるように日本語に置き換える。必要であれば、英単語を併記するか、英単語に戻せるように単語帳を用意する。文字数がなるべく多くならないように、日常使っていない単語を選んだ場合もある。文字数が多くならないお勧めの単語があればcomment欄にお書きくださると幸いです。

English	日本語	註
Abstract	抽象
Classic	古典
Adaptive	適用
communication	通信
platform	土台
test	試験
acceptance	受入れ
case	事例
description	記述
bookean	真偽
access	接続
control	制御
decision	決定
polycy	方針
system	系
interface	界面
value	値
caller	呼出元
identity	識別
environment	環境
circumstance	状況
specification	仕様
deploy	展開
model	模型
design	設計
data	与件
meta	超
executable	実行可能体
entity	実体
template	雛型
infrastructure	基盤
callback	呼戻し
callout	呼出し
runtime	実行（時）
driver	駆動
organization	組織
embody	統合

もっと短い単語が思いついていない。
実行可能体(executable) 実行体でいいかも。
最終利用者(end user)　利用者でいいかも。endは無理に訳さなくても。end userじゃないuserは,
programmerかoperaterで誤解しない.

4 Definitions

No.	Term	Japanese	Original	O.Japanse	Proposed	P.Japanese	comment
4.1	Abstract Platform	抽象土台	A Software Platform defined by AUTOSAR for the definition of functional level communications independent of Classic / Adaptive / Offboard deployments.	古典/適用/OBD展開に依存しない機能通信を定義するAUTOSAR ソフトウェア土台	A Software Platform defined by AUTOSAR for common definition of Classic and Adaptive Platform.	AUTOSARによる古典土台（CP)、適応土台（AP)の共通のソフトウェア土台。
4.2	Acceptance Test Suite	受入試験集	A test case description used in the context of Acceptance Testing	受け入れ試験で使う試験事例記述
4.3	Access Control Decision	接続制御決定	The Access Control Decision is a Boolean value indicating if the requested operation is permitted or not. It is based on the identity of the caller and the “Access Control Policy”(4.4)	接続制御決定は必要な操作を許可するどうかを示す真偽値です。呼出元の識別と「接続制御方針」(4.4) に基く。
4.4	Access Control Policy	接続制御方針	Access Control Policies are bound to the targets of calls (i.e. Service interfaces) and are used to express what “Identity Information” is necessary to access those interfaces.	接続制御方針は、呼び出し対象 (例えば、サービス界面) を束縛し、それらの界面接続に必要な「識別情報」(4.159)を表現するために用いる。
4.5	Adaptability	適応性	Adaptability is the ability of a system to adjust itself to changed circumstances in its environment in order to continue to provide the intended functionality.	適応性は、意図した機能を提供し続けるために、系が環境内の変化した状況に適応する能力。
4.6	Adaptive Application	適応応用	Software that follows the Adaptive AUTOSAR specifications and therefore can be deployed onto an Adaptive Platform instance. It consists of its implementation, operational data (e.g. map data) and its meta-data given by the Application Design Model. An Adaptive Application contains at least one executable. In order to be deployable on different Adaptive Platforms, it only uses ARA programming interfaces.	AUTOSAR 適応仕様に基づいているソフトウェアは、適おう土台に展開できる。応用設計模型は、実装、運用与件 (地図与件など)、超与件で構成する。一つの適合応用は、一つの実行可能体を含む。異なる適合土台に展開できるように、ARA算譜界面のみを使用する。
4.7	Adaptive Platform Foundation	適応土台基礎	Part of an Adaptive Platform implementation, which provides standardized platform functionality to Applications via software interfaces (APIs).	ソフトウェア界面（APIs）を通じて応用に標準土台機能を提供する適合土台実装の一部			Adaptive Platform Function Clusterに用語統合を提案
4.8	Adaptive Platform Services	適応土台サービス	Standard platform services that is provided by an application which is part of AUTOSAR platform implementation.	AUTOSAR土台実装の一部として応用に提供する標準土台サービス			Adaptive Platform Function Clusterに用語統合を提案
4.9	Application	応用	A software (or program) that is specified to the solution of a problem of an end user requiring information processing for its solution.The “Software Configuration” of a software entity.	最終利用者の問題解決のソフトウェア（または算譜）で、解を処理するのに必要な情報。ソフトウェア実体の「ソフトウェア構成」(4.295)	A software that solve a problem for an end user.	最終利用者の問題を解くソフトウェア
4.10	Application Interface	応用界面	A “Port Interface” used by a “Software Component” as specified in the software component template.	「ソフトウェア要素」(4.293)で用いる「港界面」(4.226)			まぎらわしく廃止提案
4.11	Application Programming Interface	応用算譜界面	An Application Programming Interface (API) is the prescribed method of a specific software part by which a programmer writing a program can make requests to that software part.
4.12	Application Software Component	応用ソフトウェア要素	An Application Software Component is a specific “Software Component” which realizes a defined functionality on application level and runs on the AUTOSAR infrastructure. It communicates only through the AUTOSAR Runtime Environment	応用ソフトウェア要素は、応用水準で定義した機能を実現し、AUTOSAR基盤上で実行する特定の「ソフトウェア要素」です。 AUTOSAR 実行環境を介してのみ通信します。	An Application Software Component is a “Software Component” which runs on the AUTOSAR Classic Platform. It communicates through the AUTOSAR Runtime Environment, Complex driver, callback/callout or an Interrupt Service Routine.	応用ソフトウェア要素は、AUTOSAR古典土台（CP)上で実行する「ソフトウェア要素」です。 AUTOSAR 実行環境（RTE)、複合駆動、呼戻し/呼出し、または割込みサービス処理で通信します。
4.13	Architecture	構造	The fundamental organization of a system embodied in its components, their static and dynamic relationships to each other, and to the environment, and the principles guiding its design and evolution.	いくつかの要素を統合した系の基本組織は、要素間の静的および動的な関係、環境との関係、およびその設計と進化を導く原則である。	The fundamental design of a system embodied in its components, their static and/or dynamic behavior like state transitions, time series, and timing synchronization to each other and/or to their environments. The design principles will guide system evolution.	系の基本設計は、要素間または環境との間の状態遷移、時系列、時刻同期のような静的または動的な振る舞いを統合する
4.14	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. At a high level, an artifact is represented as a single conceptual file.
4.15	ASIL Decomposition	See ISO-DIS-26262-Part-1 ([7]) ID 1.7
4.16	Asserted Property		A property or quality of a design entity (e.g. SW component or system) is asserted, if the design entity guarantees that this property or quality is fulfilled.
4.17	Assessment		See ISO-DIS-26262-Part-1 ([7]), ID 1.4
4.18	Asset		An item that has been designed for use in multiple contexts.
4.19	Asynchronous Communication	非同期通信	Asynchronous communication does not block the sending software entity.The sending software entity continues its operation without getting a response from the communication partner(s).
4.20	Asynchronous Function		A “Function” is called asynchronous if the described functionality is not guaranteed to be completed the moment the function returns to the caller.
4.21	Atomic Software Component		Non-composed Software-Component.
4.22	Audit		See ISO-DIS-26262-Part-1 ([7]), ID 1.5
4.23	Authenticity		The property that data originated from its purported source.
4.24	Automotive Safety Integrity Levels		See ISO-DIS-26262-Part-1 ([7]), ID 1.7				change the term to Automotive Function asfety integrity levels
4.25	AUTOSAR Adaptive Platform		An adaptive computing platform standardized by AUTOSAR. In a narrow term, it refers to its specification. In a broad term, it may refer to an instance of Adaptive Platform implementation.
4.26	AUTOSAR Application Interface		A set of Blueprints (“Blueprint”) which are standardized by AUTOSAR and which can be used for creating AUTOSAR Interfaces (“AUTOSAR Interface”) of an “Application”. AUTOSAR interfaces that are derived from Standardized Blueprints (“Standardized AUTOSAR Blueprint”) are Standardized AUTOSAR Interfaces (“Standardized AUTOSAR Interface”).
4.27	AUTOSAR Authoring Tool		An AUTOSAR Tool used to create and modify AUTOSAR XML descriptions (“AUTOSAR XML description”).
4.28	AUTOSAR Blueprint		An AUTOSAR Blueprint is a “Blueprint” for an AUTOSAR element. It also includes that it is specified within the AUTOSAR project which attributes are mandatory to be specified for the blueprint of a specific class of AUTOSAR element types as well as how to derive an AUTOSAR object from that blueprint.
4.29	AUTOSAR Converter Tool		An AUTOSAR Tool used to create AUTOSAR XML files by converting information from other AUTOSAR XML files.
4.30	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.
4.31	AUTOSAR Interface
4,32	AUTOSAR Meta-model
4.33	AUTOSAR Model
4.34	AUTOSAR Partial Model
4.35	AUTOSAR Processor Tool
4.36	AUTOSAR Runtime for Adaptive Applications(ARA)
4.37	AUTOSAR Run-Time Interface
4.38	AUTOSAR Service
4.39	AUTOSAR Software
4.40	AUTOSAR Tool
4.41	AUTOSAR XML description
4.42	AUTOSAR XML Schema
4.43	Availability
4.44	Basic Software(BSW)
4.45	Basic Software Module
4.46	Bit Position
4.47	Blueprint
4.48	Bulk Data
4.49	Bus Mirroring
4.50	Bus Wake-Up
4/51	Bypassing						change term to Functionality Pypassinc
4.52	Calibration
4.53	Call Point
4.54	Callback
4.55	Callout
4.56	Can XL
4.57	Cascaded Switch
4.58	Cascading Failure
4.59	Category 1 Interrupt						change term to Interrupt without OS
4.60	Category 2 Interrupt						change term to Interrupt with OS
4.61	Causality of Transmission
4.62	Classic Platform
4.63	Client
4.64	Client-Server Communication
4.65	Client-Server Interface
4.66	Cluster Signal
4.67	Code Generator
4.68	Code Variant Coding
4.69	Common Cause Failure
	Communication Attribute
	Complex Driver
	Composition
	Compositionality
	Conditioned Signal
	Confidentiality
	Configuration
	Confirmation
	Connector
	Control Flow
	Coordinate
	Data
	Data Element
	Data Flow
	Data Variant Coding
	Deadline
	Debugging
	Dependability
	Dependent Failure
	Diagnostic Coverage
	Diagnostic Event
	Diversity
	Dynamic PDU
	Dynamic Routing

追加用語

Communication Management
Diagnostics
Diagnostic Communication

出現規格

4.2 Acceptance Test Suite[1]

[1] ISO 9646 Information technology Open Systems Interconnection Conformance testing methodology and framework Part 1: General concepts
https://www.iso.org/standard/17473.html

Nomative Reference

ISO 7498: 1984, Information processing systems - Open Systems Interconnection - Basic Reference Model.
(See also CCITT Recommendation X. 200 (1984))
ISO/TR 8509: 1987, Information processing systems - Open Systems Interconnection - Service conventions.
(See also CCITT Recommendation X. 210 (1988))
ISO/IEC 8825:1990, Information technology - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1).
(See also CCITT Recommendation X. 210 (1988))
ISO/IEC 9646-2: 1994, Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 2: Abstract Test Suite specification.
(See also CCITT Recommendation X .209 (1988))
ISO/IEC 9646-3: 1992, Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 3: The Tree and Tabular Combined Notation (TTCN).
(See also ITU-T Recommendation X. 292 (1993))
ISO/IEC 9646-3 Amd 1:-1), Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 3: The Tree and Tabular Combined Notation - Amendment 1: TTCN extensions.
ISO/IEC 9646-4: 1994, Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 4: Test realization.
(See also ITU-T Recommendation X. 293 -1))
ISO/IEC 9646-5: 1994, Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 5: Requirements on test laboratories and clients for the conformance assessment process.
ISO/IEC 9646-6: 1994, Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 6: Protocol profile test specification.
(See also ITU-T Recommendation X. 295 -1)).
ISO/IEC 9646-7: -l), Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 7: Implementation Conformance Statements.(See also ITU-T Recommendation X .296 -1)).
ISO/IEC TR 10000-1: 1990, Information technology - Framework and taxonomy of International Standardized Profiles, Part 1 - Framework.

4.9 Application [2]

[2] ISO/IEC 2382 Part 20 Information technology – Vocabulary – System Develop- ment, First Edition
すでに改訂して一つにまとまっている。国際規格の参照を改訂してくれないのはなんで。
ISO/IEC 2382:2015　Information technology　Vocabulary
https://www.iso.org/standard/63598.html
https://www.iso.org/obp/ui/#iso:std:iso-iec:2382:ed-1:v2:en
Normative Reference, Bibliographyはない。古い2382のどのPartから持ってきたかを示している。
そのPartが何を参照したかを記録していない。ISO残念。

4.11 Application Programming Interface[3]

[3] ISO 17356-3:Road vehicles – Open interface for embedded automotive applica- tions – Part 3:OSEK/VDX Operating System (OS)
https://www.iso.org/standard/40079.html

Normative Reference [4]

[4] ISO 17356-1, Road vehicles — Open interface for embedded automotive applications — Part 1: General structure and terms, definitions and abbreviations terms
ISO 17356-2, Road vehicles — Open interface for embedded automotive applications — Part 2: OSEK/VDX specifications for binding OS, COM and NM
ISO 17356-6, Road vehicles — Open interface for embedded electronic equipment — Part 6: OSEK/VDX Implementation Language (OIL)

4.13 Architecture

[5] ITEA Project 00009 EAST-EEA Embedded Electronic Architecture - Glossary Version 6.1
https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://itea4.org/project/result/download/5457/EAST-EEA%2520Project%2520results%2520leaflet.pdf&ved=2ahUKEwj_qbvzi7KFAxXLgFYBHQa-CzgQFnoECBIQAQ&usg=AOvVaw27i2rkRlSB8rHGbygow5fC
https://itea4.org/itea-publication.html

[6] IEEE 1471-2000:IEEE Recommended Practice for Architectural Description for Software-Intensive Systems
https://webstore.iec.ch/preview/info_isoiec42010%7Bed1.0%7Den.pdf
Withdrawn

Reference

IEEE Std 610.12−1990, IEEE Standard Glossary of Software Engineering Terminology.1
IEEE/EIA Std 12207.0−1996, IEEE/EIA Standard—Industry Implementation of ISO/IEC 12207: 1995,
Information Technology—Software life cycle processes.

廃止後はISO/IEC/IEEEの共同発行規格になっている。

ISO/IEC/IEEE 42010:2022 Software, systems and enterprise Architecture description
https://www.iso.org/standard/74393.html

3.2　architecture
fundamental concepts or properties of an entity in its environment (3.13) and governing principles for the realization and evolution of this entity and its related life cycle processes　[SOURCE:ISO/IEC/IEEE 42020:2019, 3.3, modified — The notes to entry have been removed.]

Bibliography

[1] IEEE 1471:2000, IEEE Recommended Practice for Architectural Description for Software-Intensive Systems
[2] ISO/IEC 10746-1, Information technology — Open Distributed Processing — Reference model: Overview — Part 1:
[3] ISO/IEC 10746-2, Information technology — Open distributed processing — Reference model: Foundations — Part 2:
[4] ISO/IEC 10746-3, Information technology — Open distributed processing — Reference model: Architecture — Part 3:
[5] ISO/IEC/IEEE 12207:2017, Systems and software engineering — Software life cycle processes
[6] ISO/IEC/IEEE 15288:2015, Systems and software engineering — System life cycle processes
[7] ISO/IEC/IEEE 15289:2019, Systems and software engineering — Content of life-cycle information items (documentation)
[8] ISO/IEC 15414, Information technology — Open distributed processing — Reference model — Enterprise language
[9] ISO 15704:2019, Enterprise modelling and architecture — Requirements for enterprise-referencing architectures and methodologies
[10] ISO 19439:2006, Enterprise integration — Framework for enterprise modelling
[11] ISO 19440:2020, Enterprise modelling and architecture — Constructs for enterprise modelling
[12] ISO/PAS 19450:2015, Automation systems and integration — Object-Process Methodology
[13] ISO/IEC 19793:2015, Information technology — Open Distributed Processing — Use of UML for ODP system specifications
[14] ISO/IEC 20246:2017, Software and systems engineering — Work product reviews
[15] ISO/IEC/IEEE 24748-1:2018, Systems and software engineering — Life cycle management — Part 1: Guidelines for life cycle management
[16] ISO/IEC/IEEE 24765:2017, Systems and software engineering — Vocabulary
[17] ISO/IEC 25010:2011, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models
[18] ISO/IEC 25012:2008, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Data quality model
[19] ISO/IEC 25024:2015, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Measurement of data quality
[20] ISO/IEC 33001:2015, Information technology — Process assessment — Concepts and terminology
[21] ISO/IEC TS 33060:2020, Information technology — Process assessment — Process assessment model for system life cycle processes
[22] ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description
[23] ISO/IEC/IEEE 42020:2019, Software, systems and enterprise — Architecture processes
[24] ISO/IEC/IEEE 42030:2019, Software, systems and enterprise — Architecture evaluation framework
[25] Atkinson C., Gerbig R., Tunjic C., “A multi-level modelling environment for SUM-based software engineering”, Proceedings of the 1st Workshop on View-Based, Aspect-Oriented and Orthographic Software Modelling (VAO '13), ACM Press, 2013
[26] Boucké N., Composition and relations of architectural models supported by an architectural description language. Doctoral dissertation, Katholieke Universiteit Leuven, October 2009
[27] Callo-Arias T.B., America P., Avgeriou P., “Defining execution viewpoints for a large and complex software-intensive system”, Proceedings of WICSA/ECSA 2009
[28] Clements P., Bachmann F., Bass L., Garlan D., Ivers J., Little R. et al., Documenting Software Architectures: Views and Beyond. Addison-Wesley, Boston, 2002
[29] Darnton G., Giacoletto S., Information in the Enterprise. Digital Press, Burlington, MA, 1992
[30] Dijkstra E.W., On the role of scientific thought. 1974. https://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html
[31] DoD Architecture Framework, version 2.02, https://dodcio.defense.gov/library/dod-architecture-framework/
[32] Eeles P., Cripps P., The Process of Software Architecting. Addison Wesley, 2010
[33] Garlan D., Monroe R.T., Wile D., ACME: An Architecture Description Interchange, Proceedings of the 1997 conference of the Centre for Advanced Studies on Collaborative research, 7-22.
[34] Heidel R., The Reference Architecture Model RAMI 4.0 and the Industrie 4.0 component, 2019
[35] Hilliard R., “Viewpoint modelling”, First ICSE Workshop on Describing Software Architecture with UML, May 2001
[36] Industrial Internet Architecture Framework, https://www.iiconsortium.org/
[37] Magee J., Kramer J., Dynamic structure in software architectures, ACM SIGSOFT Foundations of Software Engineering (FSE), pages 3-14, 1996, Conference Sa Francisco CA October 16-18, 1996
[38] Josey A, Lankhorst M, Band I, Jonkers H, Quartel D., “An Introduction to the ArchiMate® 3.0 Specification”, June 2016
[39] Kiczales G., Lamping J., Menhdhekar A., Maeda C., Lopes C., Loingtier J.M. et al., Aspect-oriented programming. In Akșit, M., Matsuoka, S., eds.: Proceedings European Conference on Object-Oriented Programming. Volume 1241. Springer-Verlag, Berlin, Heidelberg, and New York (1997) 220–242
[40] Kruchten P.B., The ‘4+1’ View Model of Architecture. IEEE Softw. 1995, 12 (6) pp. 45–50
[41] Luckham D.C., Kenney J.J., Augustin L.M., Vera J., Bryan D., Mann W., Specification and analysis of system architecture using Rapide. IEEE Trans. Softw. Eng. 1995 April, 21 (4) pp. 336–355
[42] Muskens J., Bril R.J., Chaudron M.R.V., “Generalizing consistency checking between software views”, Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA’05), 169–180, Washington, DC: IEEE Computer Society, 2005
[43] Nuseibeh B., Kramer J., Finkelstein A., A framework for expressing the relationships between multiple views in requirements specification. IEEE Trans. Softw. Eng. 1994, 20 (10) pp. 760–773
[44] NATO. Architecture Framework version 4, https://www.nato.int/cps/en/natohq/topics_157575.htm
[45] OASIS, Reference Architecture Foundation for Service Oriented Architecture Version 1.0
[46] OMG Business Process Model and Notation (BPMN™), https://www.omg.org/spec/BPMN/About-BPMN/
[47] Systems Modelling Language Object Management Group , https://www.omg.org/spec/SysML/About-SysML/
[48] Unified Architecture Framework Object Management Group, https://www.omg.org/spec/UAF/About-UAF/
[49] Unified Modelling Language Object Management Group , (UML®), https://www.omg.org/spec/UML/About-UML/
[50] OMG UML Profile for DoDAF/MODAF, https://www.omg.org/updm/
[51] Bernus Peter, Richard Martin, Ovidiu Noran, and Arturo Molina. IFIP WG5.12 Architectures for Enterprise Integration: Twenty-Five Years of the GERAM Framework, in Goedicke M. et al., (Eds.): Advancing Research in Information and Communication Technology, IFIP AICT 600, pp. 1–24, 2021. https://doi.org/10.1007/978-3-030-81701-5_10
[52] Ran A., “ARES Conceptual Framework for Software Architecture”, M. Jazayeri, A. Ran, and F. van der Linden (eds.), Software Architecture for Product Families Principles and Practice, Boston: Addison-Wesley, 1–29, 2000
[53] Ross D.T., Structured Analysis (SA): a language for communicating ideas. IEEE Trans. Softw. Eng. 1977, SE-3 (1) pp. 16–34
[54] Rozanski N., Woods E., Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives. Addison-Wesley, 2005
[55] Sabetzadeh M., Finkelstein A., Goedicke M., “Viewpoints”, P. Laplante (ed.), Encyclopedia of Software Engineering, Taylor and Francis, 2010
[56] SABSA Institute Resource, The SABSA White Paper, W100, Published 2009
[57] Society of Automotive Engineers, Architecture Analysis & Design Language, http://www.aadl.info/
[58] Shaw M., Prospects for an engineering discipline of software. IEEE Softw. 1990 November
[59] Smolander K., “Four Metaphors of Architecture in Software Organizations: Finding out The Meaning of Architecture in Practice”, Proceedings of the 2002 International Symposium on Empirical Software Engineering (ISESE’02)
[60] ISO/IEC/IEEE 31320-1:2012, Information technology — Modeling Languages — Part 1: Syntax and Semantics for IDEF0
[61] The Open Group, ArchiMate Specification, https://www.opengroup.org/archimate-forum/archimate-overview
[62] The Open Group Architecture Framework (TOGAF), https://www.opengroup.org/togaf/
[63] Unified Architecture Method (UAM), https://www.unified-am.com/UAM/index.htm
[64] Viewpoints Repository for ISO/IEC/IEEE 42010, http://www.iso-architecture.org/viewpoints/
[65] Wright ADL website, http://www.cs.cmu.edu/~able/wright/
[66] XP Z67-140 Information Technology –ARCADIA– Method for Systems Engineering supported by its conceptual modelling language –General Description– Specification of the engineering definition method and the modelling language, AFNOR
[67] Zachman J.A., A Framework for Information Systems Architecture. IBM Syst. J. 1987, 26 (3)

[7] ISO/IEC 26262 Part 1 Road vehicles – Functional safety:Vocabulary

[8] IEEE 1517-1999:IEEE Standard for Information Technology – Software Life Cycle Processes – Reuse Processes

[11] Unified Modeling Language:Superstructure, Version 2.0, OMG Available Specifi- cation, ptc/05-07-04
http://www.omg.org/cgi-bin/apps/doc?formal/05-07-04

[13] CiA 610-1 version 1.0.0 (DSP) - CAN XL specifications and test plans - Part 1: Data link layer and physical coding sub-layer requirements http://www.can-cia.org

[14] CiA 611-1 version 1.0.0 (DSP) - CAN XL higher layer functions - Part 1:Definition of service data unit types
http://www.can-cia.org

[16] ISO/IEC 61511 Part 1 Information technology – Software life cycle process, First Edition
[17] Information processing systems – Open Systems Interconnection – Basic Reference Model https://www.iso.org ISO/IEC 7498-1:1994

[19] ISO/IEC 2382 Part 1 Information technology – Vocabulary – Fundamental Terms, Third Edition

[22] ISO 26262-6:2018 – Road vehicles – Functional Safety – Part 6:Product develop- ment at the software level
https://www.iso.org

[26] Road vehicles – Diagnostics on Controller Area Networks (CAN) – Part2:Network layer services
[27] Unified diagnostic services (UDS) – Part 1:Specification and requirements (Re- lease 2006-12)
https://www.iso.org

[29] ISO 17458-1:2013, Road vehicles - FlexRay communication system https://www.iso.org

[33] ISO 17356-1:Road vehicles – Open interface for embedded automotive applica- tions – Part 1:General structure and terms, definitions and abbreviated terms

[37] NIST:Secure Hash Standard (SHS) http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf
[38] IEEE 1588-2019:IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems
[39] ISO 17356-4:Road vehicles – Open interface for embedded automotive applica- tions – Part 4:OSEK/VDX Communication (COM)
[40] ISO 17987:2016 (all parts), Road vehicles – Local Interconnect Network (LIN) https://www.iso.org
[41] DIN 40041 Ausgabe:1990-12 Zuverlässigkeit; Begriffe
[42] IEEE Standard for a High-Performance Serial Bus http://www.1394ta.org/Technology/Specifications/specifications.htm
[43] Specification of Network Management Interface AUTOSAR_CP_SWS_NetworkManagementInterface
[44] ISO/IEC 27000:2018 Information technology - Security techniques - Information security management systems - Overview and vocabulary
https://www.iso.org
[45] ISO/IEC 2382 Part 15 Information technology – Vocabulary – Programming Lan- guages, First Edition
[46] ISO/IEC 2382 Part 1 Information technology – Vocabulary – Security, Second Edition
[49] XML Specification of Application Interfaces AUTOSAR_CP_MOD_AISpecification
[50] IEEE Standard for System, Software, and Hardware Verification and Validation

提案方針

Foundationで用いている用語に統一するのはどうだろう。
CP独自の用語は部分集合として再定義しようかなって思うんです。

Diagnostics

Service Oriented Vehicle Diagnostics

Explanation of Service-Oriented Vehicle Diagnostics

Requirements on Diagnostics

Communication Management

Requirements on E2E

Requirements on MACsec

Deterministic Communication with TSN

Time Synchronization Protocol Specification

Requirements on Time Synchronization

Specification of Synchronized Time-Base Manager

Specification of Time Synchronization over Ethernet

Specification of IEEE1722 Transport Protocol Module

Main Requirements

Glossary

Requirements on IEEE1722

Firewall in Classic AUTOSAR

Standardized M1 Models used for the Definition of AUTOSAR

Requirements on Firewall

Tracing for Adaptive Platform

Requirements on Debugging, Tracing and Profiling support of AUTOSAR Components

Requirements on Log and Trace

Protocols

Security

Specification of Secure Hardware Extensions

Requirements on Intrusion Detection System

List of known Issues of Secure Hardware Extensions

System Services

Timing Analysis and Design

Safety

Safety Requirements for AUTOSAR Adaptive Platform and AUTOSAR Classic Platform

Health Monitoring

Explanation of System Health Monitoring

Requirements on Health Monitoring Specification of Health Monitoring

Methodology and Templates

自己参照

Error一覧 error(0)
https://qiita.com/kaizen_nagoya/items/48b6cbc8d68eae2c42b8

英語(0) 一覧
https://qiita.com/kaizen_nagoya/items/680e3f5cbf9430486c7d

一覧の一覧( The directory of directories of mine.) Qiita(100)
https://qiita.com/kaizen_nagoya/items/7eb0e006543886138f39

文書履歴(document history)

ver. 0.01 初稿　20240406
ver. 0.02 add urls 20240408

最後までおよみいただきありがとうございました。

いいね　💚、フォローをお願いします。

Thank you very much for reading to the last sentence.

Please press the like icon 💚　and follow me for your happy life.

Glossary Terms and Definitions , AUTOSAR 55, R23-11 FO 英語(78)