ISO 14229-2:2021 Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services

ISO 14229-2:2021 Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services
https://www.iso.org/standard/77322.html

関係表にある規格群。
markdownでどう表現していいかわからない。
PDF出力して、画像で貼り付け。

Table 1 — Example of diagnostic/programming specifications applicable to the OSI layers

![udsfig1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51423/6e7ae6b4-1ebe-7e1a-cb52-a9ac8d6a9d9e.png)
# Normative Reference
ISO/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model

ISO 14229-1, Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer

ISO Road vehicles Diagnostics 規格調査中　100規格、100記事の方針
https://qiita.com/kaizen_nagoya/items/da41dbb1965ac4be0172

ISO Road vehicles - Diagnostics(11) 百規格百記事をめざし。
https://qiita.com/kaizen_nagoya/items/51e29d318585a4219985

# Terms and Definitions
## 3.1 gateway
networking device that transfers the PDU on different OSI layers
EXAMPLE:A network device that enables communication between control module networks that uses different communication protocols, different communication rates, etc. and that includes, but is not limited to, gateway functionalities like bridge, switch (3.3), router (3.2) or application layer routing.
## 3.2 router
networking device that transfers the PDU on OSI layers 3 and 4
## 3.3 switch
networking device that transfers the PDU on OSI layer 2

# 4.2 Abbreviated terms
Diag diagnostics
ECU electronic control unit
N/A not applicable
OSI open systems interconnection
RDiag remote diagnostics
S_AE session layer address extension
S_Data session layer data transfer service name
S_Length session layer length of data
S_Mtype session layer message type
S_PDU session layer protocol data unit
S_SA session layer source address
S_TA session layer target address
S_TAtype session layer target address type
SecureDiag secure diagnostics
SecureRDiag secure remote diagnostics
SI service identifier
SOM start of message
SPP service primitive parameter

# Bibliography

[1]	ISO/IEC 10731:1994, Information technology — Open Systems Interconnection — Basic Reference Model — Conventions for the definition of OSI services

[2]	ISO 10681-2, Road vehicles — Communication on FlexRay — Part 2: Communication layer services

[3]	ISO 13400-2, Road vehicles — Diagnostic communication over Internet Protocol (DoIP) — Part 2: Transport protocol and network layer services

[4]	ISO 14230-2, Road vehicles — Diagnostic communication over K-Line (DoK-Line) — Part 2: Data link layer

[5]	ISO 15765-2, Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) — Part 2: Transport protocol and network layer services

[6]	ISO 20794-3, Road vehicles — Clock extension peripheral interface (CXPI) — Part 3: Transport and network layer


# content

Foreword
Introduction
1 Scope
2 Normative references
3 Terms and definitions
4 Symbols and abbreviated terms
4.1 Symbols
4.2 Abbreviated terms
5 Conventions
6 Session layer services
6.1 Service interface
6.2 Service interface parameters
6.3 Service interface primitives
7 Service interface (SI) definition from application layer to session layer
7.1 SI — S_Data.req, S_Data.ind, and S_Data.conf service interface
7.2 SI — S_Data.req, S_Data.ind, and S_Data.conf service interface parameter mapping
7.3 SI — S_PDU mapping onto T_PDU and vice versa for message transmission
7.4 SI — S_Data.req
7.5 SI — S_Data.ind
7.6 SI — S_Data.conf
8 Service primitive parameters (SPP)
8.1 SPP – General 
8.2 SPP – Data type definitions 
8.3 SPP – S_Mtype, session layer message type
8.4 SPP – S_TAtype, session layer target address type
8.5 SPP – S_TA, session layer target address
8.6 SPP – S_SA, session layer source address 
8.7 SPP – S_AE, session layer address extension 
8.8 SPP – S_Length, session layer length of S_Data 
8.9 SPP – S_Data, session layer data of PDU 
8.10 SPP – S_Result, session layer result 
9 Timing parameter definition 
9.1 General application timing considerations 
9.1.1 Server
9.1.2 Client
9.2 Application timing parameter definitions – defaultSession
9.3 Example for t without enhanced response timing  P4_Server
9.4 Example for t with enhanced response timing . P4_Server
9.5 Session timing parameter definitions for the non-default session
9.6 Client and server timer resource requirements
9.7 Error handling
10 Timing handling during communication 
10.1 Physical communication 
10.1.1 Physical communication during defaultSession – without SOM.ind 
10.1.2 Physical communication during defaultSession – with SOM.ind 
10.1.3 Physical communication during defaultSession with enhanced response
timing 
10.1.4 Physical communication during a non-default session 
10.2 Functional communication 
10.2.1 Functional communication during defaultSession – without SOM.ind 
10.2.2 Functional communication during defaultSession – with SOM.ind 
10.2.3 Functional communication during defaultSession with enhanced response
timing – with SOM.ind 
10.2.4 Functional communication during non-default session – with SOM.ind 
10.3 Minimum time between client request messages 
Annex A (normative) T_PDU interface.
Annex B (informative) Vehicle diagnostic OSI layer architecture examples Bibliography 

# 6 Session layer services
6 集会層奉仕
## 6.1 Service interface
奉仕界面
The service interface defines a set of services that are needed to access the functions offered by the session layer, i.e. transmission/reception of data and setting of protocol parameters.
奉仕界面は、集会層が提供する機能に接続するために必要な一連の奉仕、つまり与件の送受信と規約引数の設定を定義します。
The service primitives define how a service user (e.g. diagnostic application) cooperates with a service provider (e.g. session layer). 
奉仕要素は、奉仕利用者（診断応用など）が奉仕提供者（集会層など）とどのように連携するかを定義する。 
To define the services, three types of service primitives are specified:
奉仕を定義するために、次の3種類の奉仕要素指定する。
— a service request primitive S_Data.request, used by the higher application layer to pass control information or data required to be transmitted to the session layer (i.e. the service provider is being requested by the service user to process control information or to transmit data);
上位の応用層が集会層に送信する必要のある制御情報又は与件を渡すために使用する奉仕要求要素S_Data.request（奉仕提供者は、制御情報の処理または与件の送信を奉仕利用者から求められる）。
— a service indication primitive S_Data.indication, used by the session layer to pass status information and received data to the higher application layer (i.e. the service user is being informed by the service provider about an internal event of the session layer or the service request of a peer
protocol layer entity service user);
奉仕表示要素S_Data.indication。集会層が状態情報と受信与件を上位の応用層に渡すために使用する（奉仕利用者に、集会層の内部行事または奉仕要求を奉仕提供者が通知する。 対等規約層存在奉仕利用者）;
— a service confirmation primitive S_Data.confirm used by the session layer to pass status information to the application layer (i.e. the service user is being informed by service provider about the result of a preceding service request of the service user).
状態情報を応用層に渡すために集会層が使用する奉仕確認要素S_Data.confirm（奉仕利用者に、奉仕利用者の先行する奉仕要求の結果を、奉仕提供者が通知する）。

primitive:要素
peer:対等
entity:存在

# 参考資料
@kazuo_reve 自動車の故障診断に関連するプログラマーになりたての方が参照するとよさそうな情報 
https://qiita.com/kazuo_reve/items/f773b320dcbf2ab316da

## 自己参照
@kazuo_reveさんの「自動車の故障診断に関連するプログラマーになりたての方が参照するとよさそうな情報」の読み方
https://qiita.com/kaizen_nagoya/items/0c6b8373f93ce52def33

ISO/IEC OSIに学ぶ
https://qiita.com/kaizen_nagoya/items/89562c52f37d6bf0a80d

IT業界における国際規格等の利用。仮説・検証（22）
https://qiita.com/kaizen_nagoya/items/0e2ab72fbddc391d4f41

OSI参照モデルの資料を作り始める（作業中）
https://qiita.com/kaizen_nagoya/items/26e1451ef4981c46b3be

<!--
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31,
Data communication.
This second edition cancels and replaces the first edition (ISO 14229-2:2013), which has been technically
revised.
The main changes are as follows:
— restructuration of the document;
— introduction of requirement numbers and names;
— technical content improvements based on implementation feedback from the automotive industry.
A list of all parts in the ISO 14229 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

Introduction
The ISO 14229 series has been established in order to define common requirements for diagnostic
systems, whatever the serial data link is.
To achieve this, the ISO 14229 series is based on the Open Systems Interconnection (OSI) Basic Reference
[1]
Model in accordance with ISO/IEC 7498-1 and ISO/IEC 10731, which structures communication
systems into seven layers. When mapped on this model, the services used by a diagnostic tester (client)
and an Electronic Control Unit (ECU, server) are structured into the following layers:
— application layer (layer 7) specified in ISO 14229-1;
— presentation layer (layer 6) specified in ISO 14229-1;
— session layer services (layer 5) specified in this document (ISO 14229-2).
Figure 1 illustrates the ISO 14229 series reference according to OSI model.
Figure 1 — ISO 14229 series reference according to OSI model

Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services
1 Scope
This document specifies common session layer services and requirements to provide independence
between unified diagnostic services (ISO 14229-1) and all transport protocols and network layer
services (e.g. ISO 13400-2 DoIP, ISO 15765-2 DoCAN, ISO 10681-2 communication on FlexRay, ISO 14230-
2 DoK-Line, and ISO 20794-3 CXPI).
This document specifies a common service primitive interface between OSI layer 5 (session) and layer 4
(transport) via so-called service request/indication/confirmation primitives.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The
Basic Model
ISO 14229-1, Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 14229-1, ISO/IEC 7498-1 and
the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
gateway
networking device that transfers the PDU on different OSI layers
EXAMPLE A network device that enables communication between control module networks that uses
different communication protocols, different communication rates, etc. and that includes, but is not limited to,
gateway functionalities like bridge, switch (3.3), router (3.2) or application layer routing.
3.2
router
networking device that transfers the PDU on OSI layers 3 and 4
3.3
switch
networking device that transfers the PDU on OSI layer 2

4 Symbols and abbreviated terms
4.1 Symbols
— empty cell/undefined
t time
4.2 Abbreviated terms
Diag diagnostics
ECU electronic control unit
N/A not applicable
OSI open systems interconnection
RDiag remote diagnostics
S_AE session layer address extension
S_Data session layer data transfer service name
S_Length session layer length of data
S_Mtype session layer message type
S_PDU session layer protocol data unit
S_SA session layer source address
S_TA session layer target address
S_TAtype session layer target address type
SecureDiag secure diagnostics
SecureRDiag secure remote diagnostics
SI service identifier
SOM start of message
SPP service primitive parameter
5 Conventions
[1]
This document is based on the OSI service conventions as specified in ISO/IEC 10731 .
Annex B describes vehicle diagnostic OSI layer architecture examples.
6 Session layer services
6.1 Service interface
The service interface defines a set of services that are needed to access the functions offered by the
session layer, i.e. transmission/reception of data and setting of protocol parameters.

The service primitives define how a service user (e.g. diagnostic application) cooperates with a service
provider (e.g. session layer). To define the services, three types of service primitives are specified:
— a service request primitive S_Data.request, used by the higher application layer to pass control
information or data required to be transmitted to the session layer (i.e. the service provider is being
requested by the service user to process control information or to transmit data);
— a service indication primitive S_Data.indication, used by the session layer to pass status
information and received data to the higher application layer (i.e. the service user is being informed
by the service provider about an internal event of the session layer or the service request of a peer
protocol layer entity service user);
— a service confirmation primitive S_Data.confirm used by the session layer to pass status information
to the application layer (i.e. the service user is being informed by service provider about the result
of a preceding service request of the service user).
6.2 Service interface parameters
The session layer services have the same general format. Service primitives are written in the form:
service_name.type  (
                    parameter A,
                    parameter B,
                    parameter C,
                    [parameter X],
                    ...
                    )
where
— “service_name” is the name of the service (e.g. S_Data),
— “type” indicates the type of the service primitive (e.g. request, indication, confirm),
— “parameter A, ...” is the S_PDU (session layer protocol data unit) as a list of values passed by the
service primitive (e.g. addressing information, data, length, result),
— “parameter A, parameter B, parameter C” are mandatory parameters that are included in all service
calls, “[parameter X]” is an optional parameter that is included if specific conditions are fulfilled.
6.3 Service interface primitives
Figure 2 shows the session layer service primitives of a message transmission with a T_Data.ind
reception at the session layer of the receiver side from the lower OSI layer.
Figure 2 — Session layer service primitives – T_Data.ind message reception
Figure 3 shows the session layer service primitives of a message transmission with a T_DataSOM.ind
reception at the beginning of the message and a T_Data.ind reception at the end of the message at the
session layer of the receiver side from the lower OSI layer.

Key
1 transport layer StartOfMessage data indication, e.g. ISO 15765-2
Figure 3 — Session layer service primitives – T_DataSOM.ind and T_Data.ind reception
The following communication scenarios are distinguished:
a) physical communication during
1) default session, and
2) non-default session — session handling required;
b) functional communication during
1) default session, and
2) non-default session — session handling required.
7 Service interface (SI) definition from application layer to session layer
7.1 SI — S_Data.req, S_Data.ind, and S_Data.conf service interface
The service interface defines the service and parameter mapping from the application layer to the
session layer.
Figure 4 shows the S_Data.req, S_Data.ind, and S_Data.conf service interface.

Key
1 service access point
2 read back from N-layer service provider
Figure 4 — S_Data.req and S_Data.ind service interface
7.2 SI — S_Data.req, S_Data.ind, and S_Data.conf service interface parameter mapping
This requirement specifies the application service interface and parameter mapping between the
session layer and the lower OSI layers.
REQ 0.1 SI — S_Data.req, S_Data.ind, and S_Data.conf service interface parameter mapping
The S_Data.req, S_Data.ind, and S_Data.conf service interface parameter mapping shall be implemented as
specified in Table 1.
Table 1 — S_Data.req and S_Data.ind service interface parameter mapping
Application layer Session layer A_Data.req, A_Data.ind and A_Data.conf parameter valid-
ity
(service user) (service provider) .req .ind .conf
A_Mtype S_Mtype
X X X
A_AI[TAtype] S_AI[TAtype]
X X X
A_AI[TA] S_AI[TA]
X X X
A_AI[SA] S_AI[SA]
X X X
A_AI[AE] S_AI[AE]
X X X
A_Length S_Length
X X —
A_Data S_Data
X X —
A_Result S_Result
— X X
Key
X = supported
— = not supported
7.3 SI — S_PDU mapping onto T_PDU and vice versa for message transmission
The parameters of the session layer protocol data unit defined to request the transmission of a
diagnostic service request/response are mapped onto the parameters of the transport layer protocol data unit for the transmission of a message in the client/server. Annex A specifies the T_PDU interface
and shall be followed.
The parameters of the transport layer protocol data unit defined for the reception of a message are
mapped as follows onto the parameters of the session layer protocol data unit for the confirmation/
indication of the reception of a diagnostic response/request.
The transport layer confirmation of the successful transmission of the message (T_Data.conf) is
forwarded to the application, because it is needed in the application for starting those actions, which
shall be executed immediately after the transmission of the request/response message (e.g. ECUReset,
bit rate change).
The transport layer indication for the reception of a StartOfMessage T_PDU (T_DataSOM.ind), e.g.
ISO 15765-2 is not forwarded to the application layer, because it is only used within the session layer
to perform the session layer timing (see Clause 9). Therefore, no mapping of the T_DataSOM.ind T_PDU
onto an S_PDU is defined.
Table 2 defines the mapping of session layer S_PDU onto transport layer T_PDU and vice versa.
Table 2 — Mapping of session layer S_PDU onto transport layer T_PDU and vice versa
S_PDU parameter Description T_PDU parameter Description
(session layer pro- (transport layer pro-
tocol data unit) tocol data unit)
S_Mtype T_Ptype
Session layer message type Transport layer segment type
S_AI[TAtype] T_AI[TAtype]
Session layer target address Transport layer target address
type type
S_AI[SA] T_AI[SA]
Session layer source address Transport layer source address
S_AI[TA] T_AI[TA]
Session layer target address Transport layer target address
a a
S_AI[AE] Session layer address exten- T_AI[AE] Transport layer address exten-
sion sion
S_Data[1] – S_ Session layer data T_Data[1] – T_
Transport layer data
Data[n] Data[n]
S_Length T_Length
Session layer data length Transport layer data length
S_Result T_Result
Session layer result Transport layer result
If Mtype = diagnostics/secure diagnostics, then the address information shall consist of the parameters SA, TA and
TAtype.
If Mtype = remote diagnostics/secure remote diagnostics, then the address information shall consist of the parameters
SA, TA, TAtype, and AE.
7.4 SI — S_Data.req
The service primitive requests transmission of S_Data with S_Length number of bytes from the sender
to the receiver peer entities identified by the address information in S_AI[TAtype], S_AI[SA], S_
AI[TA], and S_AI[AE].
If the S_Data.req service is called, the session layer signals the completion (or failure) of the message
transmission to the service user by means of the issuing of an S_Data.conf service call.
S_Data.req    (
              S_Mtype,
              S_AI[TAtype],
              S_AI[SA],
              S_AI[TA],
              [S_AI[AE]],
              S_Data[Data#1, Data#2, …, Data#n],
              S_Length
              )

7.5 SI — S_Data.ind
The S_Data.indication service is issued by the session layer. The service primitive shall indicate S_
Result events and delivers S_Data with S_Length bytes received from a peer protocol entity identified
by the address information in S_AI[TAtype], S_AI[SA], S_AI[TA], and S_AI[AE] to the adjacent upper
layer. The parameters S_Data and S_Length shall only be valid if S_Result equals S_OK.
S_Data.ind    (
              S_Mtype,
              S_AI[TAtype],
              S_AI[SA],
              S_AI[TA],
              [S_AI[AE]],
              S_Data[Data#1, Data#2, …, Data#n],
              S_Length,
              S_Result
             )
7.6 SI — S_Data.conf
The S_Data.conf service is issued by the session layer. The service primitive confirms the completion
of an S_Data.req service identified by the address information in S_AI[TAtype], S_AI[SA], S_AI[TA],
and S_AI[AE]. The parameter S_Result provides the status of the service request.
S_Data.conf   (
              S_Mtype,
              S_AI[TAtype],
              S_AI[SA],
              S_AI[TA],
              [S_AI[AE]],
              S_Result
              )
8 Service primitive parameters (SPP)
8.1 SPP – General
Clause 8 specifies the service primitive parameters and data types, which are used by the application
layer services.
8.2 SPP – Data type definitions
REQ 0.2 SPP – Data type definitions
The data types shall be in accordance to:
— Enum = 8-bit enumeration,
— Unsigned Byte = 8-bit unsigned numeric value,
— Unsigned Word = 16-bit unsigned numeric value,
— Unsigned Long = 32-bit unsigned numeric value,
— Byte Array = sequence of 8-bit aligned data,
— Bit String = 8-bit binary coded.
8.3 SPP – S_Mtype, session layer message type
The parameter S_Mtype is used to identify the type and range of address information parameters
included in a service call. This document specifies a range of two values for this parameter.
© ISO 2021 – All rights reserved
---------------------- Page: 13 ----------------------
ISO 14229-2:2021(E)
REQ 0.3 SPP – S_Mtype, session layer message type
The S_Mtype parameter shall be of data type Enum and shall be used to identify the message type and range of
address information included in a service call.
— If S_Mtype = diagnostics (Diag)/secure diagnostics (SecureDiag), then the address information shall
consist of the parameters S_SA, S_TA and S_TAtype.
— If S_Mtype = remote diagnostics (RDiag)/secure remote diagnostics (SecureRDiag), then the address
information shall consist of the parameters S_SA, S_TA, S_TAtype and S_AE.
Range: [Diag, RDiag, SecureDiag, SecureRDiag]
8.4 SPP – S_TAtype, session layer target address type
The parameter S_TAtype is a configuration attribute to the S_TA parameter. It is used to encode the
communication model used by the communicating peer entities. Two communication models are
specified: '1 to 1' communication, called physical addressing, and '1 to n' communication, called
functional addressing.
REQ 0.4 SPP – S_TAtype, session layer target address type
The S_TAtype parameter shall be of data type Enum and shall be used to identify the target address type to be
used with the request address.
Range: [physical, functional]
8.5 SPP – S_TA, session layer target address
S_TA parameter is used to encode the receiving session layer protocol entity. The parameter S_TA is
used to encode client and server identifiers.
REQ 0.5 SPP – S_TA, session layer target address
The S_TA parameter shall be of data type Unsigned Word and shall contain the target address of the node.
Range: [0000  to FFFF ]
16 16
8.6 SPP – S_SA, session layer source address
S_SA parameter is used to encode the sending session layer protocol entity. The parameter S_SA is used to enco
-->


<この項は書きかけです。順次追記します。>
This article is not completed. I will add some words and/or centences in order.
Este artículo no está completo. Agregaré algunas palabras en orden.

## 知人資料
' @kazuo_reve 私が効果を確認した「小川メソッド」
https://qiita.com/kazuo_reve/items/a3ea1d9171deeccc04da

' @kazuo_reve 新人の方によく展開している有益な情報
https://qiita.com/kazuo_reve/items/d1a3f0ee48e24bba38f1

' @kazuo_reve Vモデルについて勘違いしていたと思ったこと
https://qiita.com/kazuo_reve/items/46fddb094563bd9b2e1e

## 自己記事一覧
Qiitaで逆リンクを表示しなくなったような気がする。時々、スマフォで表示するとあらわることがあり、完全に削除したのではなさそう。2024年４月以降、せっせとリンクリストを作り、統計を取って確率を説明しようとしている。2025年２月末を目標にしていた。

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

仮説（0）一覧（目標100現在40）
https://qiita.com/kaizen_nagoya/items/f000506fe1837b3590df

Qiita(0)Qiita関連記事一覧（自分）
https://qiita.com/kaizen_nagoya/items/58db5fbf036b28e9dfa6

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

C++ Support(0)　
https://qiita.com/kaizen_nagoya/items/8720d26f762369a80514

Coding(0) Rules, C, Secure, MISRA and so on
https://qiita.com/kaizen_nagoya/items/400725644a8a0e90fbb0

Ethernet 記事一覧　Ethernet(0)
https://qiita.com/kaizen_nagoya/items/88d35e99f74aefc98794

Wireshark 一覧 wireshark(0)、Ethernet(48) 
https://qiita.com/kaizen_nagoya/items/fbed841f61875c4731d0

線網（Wi-Fi）空中線(antenna)(0) 記事一覧(118/300目標)
https://qiita.com/kaizen_nagoya/items/5e5464ac2b24bd4cd001

なぜdockerで機械学習するか 書籍・ソース一覧作成中 (目標100)
https://qiita.com/kaizen_nagoya/items/ddd12477544bf5ba85e2

プログラムちょい替え（0）一覧:4件
https://qiita.com/kaizen_nagoya/items/296d87ef4bfd516bc394

言語処理100本ノックをdockerで。python覚えるのに最適。:10+12
https://qiita.com/kaizen_nagoya/items/7e7eb7c543e0c18438c4

Python(0)記事をまとめたい。
https://qiita.com/kaizen_nagoya/items/088c57d70ab6904ebb53

安全（0）安全工学シンポジウムに向けて: 21
https://qiita.com/kaizen_nagoya/items/c5d78f3def8195cb2409

プログラマによる、プログラマのための、統計(0)と確率のプログラミングとその後
https://qiita.com/kaizen_nagoya/items/6e9897eb641268766909

転職(0)一覧
https://qiita.com/kaizen_nagoya/items/f77520d378d33451d6fe

技術士(0)一覧
https://qiita.com/kaizen_nagoya/items/ce4ccf4eb9c5600b89ea

Reserchmap(0) 一覧
https://qiita.com/kaizen_nagoya/items/506c79e562f406c4257e

物理記事　上位100
https://qiita.com/kaizen_nagoya/items/66e90fe31fbe3facc6ff

量子(0) 計算機, 量子力学 
https://qiita.com/kaizen_nagoya/items/1cd954cb0eed92879fd4

数学関連記事１００
https://qiita.com/kaizen_nagoya/items/d8dadb49a6397e854c6d

coq(0) 一覧
https://qiita.com/kaizen_nagoya/items/d22f9995cf2173bc3b13

統計(0)一覧
https://qiita.com/kaizen_nagoya/items/80d3b221807e53e88aba

図(0) state, sequence and timing. UML and お絵描き 
https://qiita.com/kaizen_nagoya/items/60440a882146aeee9e8f

色(0) 記事100書く切り口 
https://qiita.com/kaizen_nagoya/items/22331c0335ed34326b9b

品質一覧 
https://qiita.com/kaizen_nagoya/items/2b99b8e9db6d94b2e971

言語・文学記事　１００
https://qiita.com/kaizen_nagoya/items/42d58d5ef7fb53c407d6

医工連携関連記事一覧
https://qiita.com/kaizen_nagoya/items/6ab51c12ba51bc260a82

水の資料集(0)　方針と成果
https://qiita.com/kaizen_nagoya/items/f5dbb30087ea732b52aa

自動車　記事　１００
https://qiita.com/kaizen_nagoya/items/f7f0b9ab36569ad409c5

通信記事１００
https://qiita.com/kaizen_nagoya/items/1d67de5e1cd207b05ef7

日本語（０）一欄
https://qiita.com/kaizen_nagoya/items/7498dcfa3a9ba7fd1e68

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

音楽　一覧(0) 
https://qiita.com/kaizen_nagoya/items/b6e5f42bbfe3bbe40f5d

「@kazuo_reve 新人の方によく展開している有益な情報」確認一覧 
https://qiita.com/kaizen_nagoya/items/b9380888d1e5a042646b

鉄道（０）鉄道のシステム考察はてっちゃんがてつだってくれる
https://qiita.com/kaizen_nagoya/items/faa4ea03d91d901a618a

OSEK OS設計の基礎　OSEK(100)
https://qiita.com/kaizen_nagoya/items/7528a22a14242d2d58a3

coding (101) 一覧を作成し始めた。omake:最近のQiitaで表示しない5つの事象
https://qiita.com/kaizen_nagoya/items/20667f09f19598aedb68

官公庁・学校・公的団体（NPOを含む）システムの課題、官（０）
https://qiita.com/kaizen_nagoya/items/04ee6eaf7ec13d3af4c3

「はじめての」シリーズ　 ベクタージャパン　
https://qiita.com/kaizen_nagoya/items/2e41634f6e21a3cf74eb

AUTOSAR(0)Qiita記事一覧, OSEK(75)
https://qiita.com/kaizen_nagoya/items/89c07961b59a8754c869

プログラマが知っていると良い「公序良俗」
https://qiita.com/kaizen_nagoya/items/9fe7c0dfac2fbd77a945

LaTeX(0) 一覧　
https://qiita.com/kaizen_nagoya/items/e3f7dafacab58c499792

自動制御、制御工学一覧（０）
https://qiita.com/kaizen_nagoya/items/7767a4e19a6ae1479e6b

Rust(0) 一覧　
https://qiita.com/kaizen_nagoya/items/5e8bb080ba6ca0281927

programの本質は計画だ。programは設計だ。
https://qiita.com/kaizen_nagoya/items/c8545a769c246a458c27

登壇直後版 色使い(JIS安全色) Qiita Engineer Festa 2023〜私しか得しないニッチな技術でLT〜 スライド編 0.15
https://qiita.com/kaizen_nagoya/items/f0d3070d839f4f735b2b

プログラマが知っていると良い「公序良俗」
https://qiita.com/kaizen_nagoya/items/9fe7c0dfac2fbd77a945

逆も真：社会人が最初に確かめるとよいこと。OSEK(69)、Ethernet(59)
https://qiita.com/kaizen_nagoya/items/39afe4a728a31b903ddc

統計の嘘。仮説（127）
https://qiita.com/kaizen_nagoya/items/63b48ecf258a3471c51b

自分の言葉だけで論理展開できるのが天才なら、文章の引用だけで論理展開できるのが秀才だ。仮説（136）
https://qiita.com/kaizen_nagoya/items/97cf07b9e24f860624dd

参考文献駆動執筆(references driven writing)・デンソークリエイト編
https://qiita.com/kaizen_nagoya/items/b27b3f58b8bf265a5cd1

「何を」よりも「誰を」。１０年後のために今見習いたい人たち
https://qiita.com/kaizen_nagoya/items/8045978b16eb49d572b2

Qiitaの記事に３段階または５段階で到達するための方法
https://qiita.com/kaizen_nagoya/items/6e9298296852325adc5e

出力(output)と呼ばないで。これは状態(state)です。
https://qiita.com/kaizen_nagoya/items/80b8b5913b2748867840

祝休日・謹賀新年 2025年の目標
https://qiita.com/kaizen_nagoya/items/dfa34827932f99c59bbc

Qiita 1年間をまとめた「振り返りページ」＠2024
https://qiita.com/kaizen_nagoya/items/ed6be239119c99b15828

2024 参加・主催Calendarと投稿記事一覧 Qiita(248)
https://qiita.com/kaizen_nagoya/items/d80b8fbac2496df7827f

主催Calendar2024分析 Qiita(254)
https://qiita.com/kaizen_nagoya/items/15807336d583076f70bc

Calendar 統計
https://qiita.com/kaizen_nagoya/items/e315558dcea8ee3fe43e

LLM 関連 Calendar 2024 
https://qiita.com/kaizen_nagoya/items/c36033cf66862d5496fa

Large Language Model Related Calendar 
https://qiita.com/kaizen_nagoya/items/3beb0bc3fb71e3ae6d66

博士論文 Calendar 2024 を開催します。 
https://qiita.com/kaizen_nagoya/items/51601357efbcaf1057d0

博士論文(0)関連記事一覧
https://qiita.com/kaizen_nagoya/items/8f223a760e607b705e78

coding (101) 一覧を作成し始めた。omake:最近のQiitaで表示しない5つの事象
https://qiita.com/kaizen_nagoya/items/20667f09f19598aedb68

あなたは「勘違いまとめ」から、勘違いだと言っていることが勘違いだといくつ見つけられますか。人間の間違い(human error(125))の種類と対策
https://qiita.com/kaizen_nagoya/items/ae391b77fffb098b8fb4

プログラマの「プログラムが書ける」思い込みは強みだ。３つの理由。仮説（168）統計と確率(17) , OSEK(79)
https://qiita.com/kaizen_nagoya/items/bc5dd86e414de402ec29

出力(output)と呼ばないで。これは状態(state)です。
https://qiita.com/kaizen_nagoya/items/80b8b5913b2748867840

これからの情報伝達手段の在り方について考えてみよう。炎上と便乗。
https://qiita.com/kaizen_nagoya/items/71a09077ac195214f0db

ISO/IEC JTC1 SC7 Software and System Engineering
https://qiita.com/kaizen_nagoya/items/48b43f0f6976a078d907

アクセシビリティの知見を発信しよう！（再び）
https://qiita.com/kaizen_nagoya/items/03457eb9ee74105ee618

統計論及確率論輪講（再び）
https://qiita.com/kaizen_nagoya/items/590874ccfca988e85ea3

読者の心をグッと惹き寄せる7つの魔法
https://qiita.com/kaizen_nagoya/items/b1b5e89bd5c0a211d862

「@kazuo_reve 新人の方によく展開している有益な情報」確認一覧
https://qiita.com/kaizen_nagoya/items/b9380888d1e5a042646b

ソースコードで議論しよう。日本語で議論するの止めましょう（あるプログラミング技術の議論報告）
https://qiita.com/kaizen_nagoya/items/8b9811c80f3338c6c0b0

脳内コンパイラの3つの危険
https://qiita.com/kaizen_nagoya/items/7025cf2d7bd9f276e382

心理学の本を読むよりはコンパイラ書いた方がよくね。仮説（34）
https://qiita.com/kaizen_nagoya/items/fa715732cc148e48880e

NASAを超えるつもりがあれば読んでください。
https://qiita.com/kaizen_nagoya/items/e81669f9cb53109157f6

データサイエンティストの気づき!「勉強して仕事に役立てない人。大嫌い!!」『それ自分かも?』ってなった!!! 
https://qiita.com/kaizen_nagoya/items/d85830d58d8dd7f71d07

「ぼくの好きな先生」「人がやらないことをやれ」プログラマになるまで。仮説（37）　
https://qiita.com/kaizen_nagoya/items/53e4bded9fe5f724b3c4

なぜ経済学徒を辞め、計算機屋になったか（経済学部入学前・入学後・卒業後対応） 転職(1)  
https://qiita.com/kaizen_nagoya/items/06335a1d24c099733f64    

プログラミング言語教育のXYZ。 仮説（52） 
https://qiita.com/kaizen_nagoya/items/1950c5810fb5c0b07be4

【24卒向け】9ヶ月後に年収１０００万円を目指す。二つの関門と三つの道。
https://qiita.com/kaizen_nagoya/items/fb5bff147193f726ad25

「【25卒向け】Qiita Career Meetup for STUDENT」予習の勧め
https://qiita.com/kaizen_nagoya/items/00eadb8a6e738cb6336f

大学入試不合格でも筆記試験のない大学に入って卒業できる。卒業しなくても博士になれる。
https://qiita.com/kaizen_nagoya/items/74adec99f396d64b5fd5

全世界の不登校の子供たち「博士論文」を書こう。世界子供博士論文遠隔実践中心 安全(99)
https://qiita.com/kaizen_nagoya/items/912d69032c012bcc84f2

日本のプログラマが世界で戦える16分野。仮説(53),統計と確率(25) 転職(32)、Ethernet(58)
https://qiita.com/kaizen_nagoya/items/a7e634a996cdd02bc53b

小川メソッド　覚え（書きかけ）
https://qiita.com/kaizen_nagoya/items/3593d72eca551742df68

DoCAP（ドゥーキャップ）って何ですか？
https://qiita.com/kaizen_nagoya/items/47e0e6509ab792c43327

views 20,000越え自己記事一覧
https://qiita.com/kaizen_nagoya/items/58e8bd6450957cdecd81

Views１万越え、もうすぐ１万記事一覧 最近いいねをいただいた213記事
https://qiita.com/kaizen_nagoya/items/d2b805717a92459ce853

amazon 殿堂入りNo1レビュアになるまで。仮説(102)
https://qiita.com/kaizen_nagoya/items/83259d18921ce75a91f4

100以上いいねをいただいた記事16選
https://qiita.com/kaizen_nagoya/items/f8d958d9084ffbd15d2a

水道局10年(1976,4-1986,3)を振り返る
https://qiita.com/kaizen_nagoya/items/707fcf6fae230dd349bf

小川清最終講義、最終講義（再）計画, Ethernet(100) 英語(100) 安全(100)
https://qiita.com/kaizen_nagoya/items/e2df642e3951e35e6a53

＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
This article is an individual impression based on my individual experience. It has nothing to do with the organization or business to which I currently belong.
Este artículo es una impresión personal basada en mi experiencia personal. No tiene nada que ver con la organización o empresa a la que pertenezco actualmente.
### 文書履歴(document history)
ver. 0.01 初稿 　20240428
### 最後までおよみいただきありがとうございました。
いいね　💚、フォローをお願いします。
#### Thank you very much for reading to the last sentence.
Please press the like icon 💚　and follow me for your happy life.
#### Muchas gracias por leer hasta la última oración.
Por favor, haz clic en el ícono Me gusta 💚 y sígueme para tener una vida feliz.