ISO/IEC 10731:1994, Information technology - Open Systems Interconnection - Basic Reference Model - Conventions for the definition of OSI services
2 Normative references
2.1 Identical Recommendations and International Standards
ITU-T Recommendation X.207 (1993) | ISO/IEC 9545; 1993, Information Technology — Open Systems Interconnection — Application Layer structure.
2.2 Paired Recommendations | International Standards equivalent in technical content
CCITT Recommendation X.200 (1988), Reference model of open systems for CCITT applications.
ISO/IEC 7498:1984, Information technology — Open Systems Interconnection — Basic Reference Model.
3 Definitions
3.1 Terms defined in the OSI Basic Reference Model
This Recommendation | International Standard builds on the concepts developed in CCITT Rec. X.200 | ISO 7498 and makes use of the following terms defined in that Recommendation | International Standard:
a) (N)-connection;
b) (N)-connection-endpoint;
c) (N)-entity;
d) (N)-layer;
e) open system;
f) (N)-service;
g) (N)-service-access-point;
h) (N)-subsystem.
3.2 Terms defined in the Application Layer Structure
This Recommendation | International Standard makes use of the following terms defined in ITU-T Rec. X.207 (1993) | ISO/IEC 9545:
a) application-entity-invocation;
b) application-service-element;
c) application-service-object;
d) control function.
3.3 Terms defined in this Recommendation | International Standard
NOTE — Several terms in the following list are structured with the prefix "OSI-". The terms thus prefixed are intended to have a consistent meaning across all layers of OSI, including the Application Layer.
In the case of the OSI-services provided by the six lower layers, the prefix "OSI-" can be replaced by the equivalent prefix "(N)-" which particularises the concept to the generic (N)-layer.
Further particularisation is needed in other OSI standards, such as replacing "OSI-" with the abbreviation for one of the six lower layers, or replacing "OSI-" with the abbreviation for a particular application-service-element or group of application-serviceelements which provide an OSI-service within the Application Layer.
3.3.1 OSI-service
The capability of an OSI-service-provider which is provided to OSI-service-users at the boundary between the OSI-service-provider and the OSI-service-users.
Note 1 to entry: The OSI-service defines the external behaviour of the OSI-service-provider independent of the mechanisms used to provide that behaviour. (N)-layers, (N)-entities, application-service-elements, etc. are components of an OSI-service-provider.
3.3.2 OSI-service-provider
An abstract representation of the totality of those entities which provide an OSI-service to OSI-service-users.
3.3.3 OSI-service-user
An entity in a single open system that makes use of an OSI-service.
Note 1 to entry: The OSI-service-user makes use of the OSI-service through a collection of OSI-service primitives defined for the OSI-service.
3.3.4 OSI-service primitive; primitive
An abstract, atomic, implementation-independent representation of an interaction between an OSI-service-user and its OSI-service-provider.
Note 1 to entry: The term "primitive" is used in some documents in place of the preferred form "OSI-service primitive".
3.3.5 submit (primitive)
An OSI-service primitive initiated by an OSI-service-user.
3.3.6 deliver (primitive)
An OSI-service primitive initiated by an OSI-service-provider.
3.3.7 requestor
In a particular exchange of OSI-service-primitives, an OSI-service-user that issues a submit primitive and as a result may receive one or more deliver primitives.
3.3.8 acceptor
In a particular exchange of OSI-service-primitives, an OSI-service-user that receives a deliver primitive and as a result may issue one or more submit primitives.
3.3.9 request (primitive)
requestor.submit (primitive)
A submit primitive issued by a requestor.
3.3.10 indication (primitive)
acceptor.deliver (primitive)
A deliver primitive received by an acceptor.
3.3.11 response (primitive)
acceptor.submit (primitive)
A submit primitive issued by an acceptor.
3.3.12 confirm (primitive)
requestor.deliver (primitive)
A deliver primitive received by a requestor.
3.3.13 OSI-facility
A part of an OSI-service designated within a Recommendation | International Standard.
Note 1 to entry:
1 There are existing Recommendations | International Standards for OSI-service definitions which use the form "...-service" for terms relating to such a designated part of the total OSI-service. The form "...-facility" is to be strongly preferred for all such usages.
2 The term "OSI-facility" defined here is distinguished from the term "facility" (without the qualification "OSI-") used, for example, in CCITT Rec. X.25 and ISO/IEC 8208.
3.3.14 OSI-mandatory-facility
An OSI-facility which is always provided.
3.3.15 OSI-provider-optional-facility
An OSI-facility which may or may not be provided.
3.3.16 OSI-user-optional-facility
An OSI-facility which is only used if all peer OSI-service-users agree.
3.3.17 OSI-confirmed-facility
An OSI-facility in the operation of which an explicit confirmation is given from the OSI-service-provider to the initiating OSI-service-user.
3.3.18 OSI-non-confirmed-facility
An OSI-facility in the operation of which no explicit confirmation is given from the OSI-service-provider to the initiating OSI-service-user.
3.3.19 OSI-provider-initiated-facility
An OSI-facility the operation of which is initiated by the OSI-service-provider.
3.3.20 OSI-local view
The shared behaviour of an OSI-service-user and an OSI-service-provider in terms of their interactions at an OSI-service boundary.
Note 1 to entry: In the case of (N)-services, the OSI-service boundary is to be understood as the set of (N)-service-access-points for the (N)-subsystem.
3.3.21 symmetrical service
An OSI-service for which the definitions of all OSI-local views are the same (i.e. there is only one type of OSI-local view).
3.3.22 asymmetrical service
An OSI-service for which the definitions of all OSI-local views are not all the same (i.e. there are several types of OSI-local view).
3.3.23 multi-peer
A mode of operation of an OSI-service which supports exchanges between more than two OSI-service-users.
4 Abbreviations
ASE application-service-element
AS0 application-service-object
OS1 Open Systems Interconnection
5 Model of service
5.1 The concept of ON-service definition
5.1.1 An OSI-service is that capability of an OSI-service-provider which is offered to OSI-service-users at the
boundary between the OSI-service-provider and the OSI-service-users.
5.1.2 An OSI-service definition is the complete expression of the behaviour of an OSI-service-provider as seen by
its OSI-service-users. An OSI-service definition does not describe the internal behaviour of an OSI-service-provider.
There are many mechanisms that may be specified to provide an OSI-service. It is thus fundamental that the conventions
used to define an OSI-service allow an OSI-service definition to be expressed totally independently from any subsequent
specification of the protocol or protocols which support that OSI-service.
5.1.3 To make proper use of an OSI-service, it is necessary for an OSI-service-user to reference the OSI-service
definition. As a result, an OSI-service definition constrains the behaviour of the OSI-service-users. Nevertheless, it is not
the purpose of an OSI-service definition to express the complete behaviour of OSI-service-users.
5.2 . The general model of an OSI-service definition
5.2.1 This clause describes a general model for the definition of an OSI-service which is applicable to all modes of
communication (connectionless-mode, connection-mode, multi-peer, etc.) in all seven layers.
5.2.2 An OSI-service-user and an OSI-service-provider interact at a OSI-service boundary in an open system. The
interactions between the OSI-service-user and the OSI-service-provider constitute an abstract interface at the OSI-
service boundary. This abstract interface is the OSI-local view. The OSI-local view is defmed in terms of the set of OSI-
service primitives which the OSI-service user and the OSI-service-provider are allowed’to exchange, together with the
sequencing rules which apply to these exchanges.
5.2.3 An OSI-service primitive issued by an OSI-service-user to its OSI-service-provider is a definition of:
the semantics of the information conveyed by the OSI-service primitive;
the constraints imposed on the OSI-service-user in order to issue the OSI-service primitive; and
receiving the
the requirements for action that the OSI-service-provider shall meet asa result of
OSI-service primitive.
5.2.4 An OSI-service primitive issued by an OSI-service-provider to one of its 0%service-users is a definition of:
a) the semantics of the information conveyed by the OSI-service primitive;
b) the conditions to be fulfilled by the OSI-service-provider in order to issue the OSI-service primitive; and
the possi .ble expectations of the OSI-service-provider regarding the reactions of the OSI-service-user
resulting from its receipt of the OSI-service primitive.
5.2.5 The semantics of these OSI-service primitives and the complete set of relationships among OSI-local views are
described in a model which defines the virtual environment in which the OSI-service applies. A relationship exists
among OSI-local views when there is a correlation among OSI-service primitives at each of these several OSI-local
views.
NOTES
In some cases , the model is explicitly described in a standard, in other cases e. . (N)-layer-services) the model
( g may
be implicit& known.
2 The semantics of the OSI-service primitives may be described, for example, in terms of abstract actions on abstract
objects.
3 In a simple case, the model of a peer-to-peer OSI-service establishes a one to one correspondence between the two
OSI-local views; in a more complex case, the model of an OSI-service may establish a one to many correspondence among some of
the OSI-local views participating in the OSI-service.
5.2.6 An OSI-service definition comprises:
the definition of, or reference to, the model introduced in 5.2.5;
b) the definition of the OSI-local views of relevance to the OSI-service (these definitions may all be the
same: symmetrical service, or they may not: asymmetrical service);
the definition of the correlation among OSI-service primitives for this set of OSI-local views.
5.2.7 The definition of the correlation among OSI-service primitives is itself formed by the following three
components:
the definition of, or reference to, the model introduced in 5.2.5
b) the definition of the relationships among OSI-service primitives within the scope of each OSI-local view;
based on the relationships among OSI-local views, the definition of the correlations among OSI-service
primitives that pertain to separate (but related) OSI-local views.
NOTES
1 Aspects of such a definition of the conelations among OSI-service primitives seen by different OSI-service-users
include
- the definition of the relationships among submit primitives originated at one 0%local view and deliver primitives
issued at other related OSI-local views;
- the definition of the effects of possible collisions among submit primitives originated at one OSI-local view with
submit primitives originated at other, related OSI-local views, etc.
2 Only the OSI-local view is visible to the OSI-service-user. A specific OSI-service-user is only concerned with the
exchange of OSI-service primitives at the OSI-service boundary for this OSI-local view. The possible correlation between the OSI-
service primitives seen by different OSI-service-users does not need to be known by them and, consequently, is expressed in the
correlation definition and not in the definitions of the separate OSI-local views.
3 The definition of the correlations among OSI-service primitives seen by different OSI-service users is a high-level
definition. For example, although in a particular case a correlation definition might specify that an information request primitive from
one OSI-service-user results in the receipt of information request primitives by a number of OSI-service-users holding the information
to be accessed, it would not specify how the OSI-service-users are located nor how the requests are routed to them.
5.2.8 There are two basic types of OSI-service primitive: the submit primitive invoked by the OSI-service-user to
exchange information with the OSI-service-provider, and the deliver primitive invoked by the OSI-service-provider to
exchange information with the OSI-service-user.
Figure 1 illustrates an idealized view of a complete composite OSI-service.
5.2.9 This composite OSI-service consists of several OSI-service primitives which, when executed successfully in the correct sequence, result in the objective of the initiating OSI-service-user.
NOTES
Figure 1 illustrates four OSI-service-users, of which three are participating in an exchange of OSI-service primitives
with the OSI-service-provider. Only the corresponding 0%local view is apparent to an OX-service-user.
2 While it is convenient to view the OSI-service-provider as one unit for the purposes of illustration, it must not be
overlooked that it is a distributed system. This means that the OSI-service-provider cannot be considered a single state machine; that
there are time delays between service actions, and that there exists the possibility of loss, error, and &ordering associated with real
communication.
3 If Figure 1 is reproduced in an actual OSI-service standard, it should be accompanied by explanatory text similar
to 5.2.9 and Note 2.
OSI-submit OSI-su bmit OSI-submit
OSI-deliver OSIdeliver OSIdeliver
/ \ / \ /
OSI-local-view
OSI-local-view OS l-local-view
1 I
--I--------1
OSI-ServiceProvider
-I-.--I----I
Tls0251044/do1
Figure 1 - OSI-service model
5.2.10 At a given point in time, the state of the OSI-local view of an OSI-service is completely determined by the
preceding sequence of OSI-service primitives that has been observed at the OSI-service boundary.
5.2.11 Deliver primitives issued at an OSI-local view are usually correlated to submit primitives invoked by OSI-
service-users at other OSI-local views. In some specific cases (e.g. provider initiated) a deliver primitive may be issued
without any submit primitive having been invoked at any other OSI-local view.
5.2.12 An OSI-service definition contains one or more definitions of OSI-local views. Where there is only one
definition of OSI-local views, the OSI-service is said to be symmetrical and needs no additional identification.
Correspondingly, when an OSI-service is asymmetrical, it requires names to distinguish OSI-local views having
different definitions. These names need only be unique within the OSI-service definition, but should be chosen to
facilitate understanding (e.g. CLIENT and SERVER in Annex E).
. The concepts of requestor and acceptor
参考資料
@kazuo_reve 自動車の故障診断に関連するプログラマーになりたての方が参照するとよさそうな情報
@kazuo_reve AUTOSARのClassic PlatformとAdaptive PlatformにおけるDiagnosticsの違いを整理
私のAdvent Calendar 2022 ーー はじめたきっかけ、1月のふりかえり、今後の展望
自己参照
ISO Road vehicles Diagnostics 規格調査中 100規格、100記事をめざして。
ISO Diagnostics 文献（Normative Reference and Bibliography）集め
ISO Diagnostics 用語定義(Terms and Definition)と短縮名(short name)集め
ISO/IEC OSIに学ぶ
ISO 14229-1:2020 Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer
国際規格のNormative Reference
@kazuo_reveさんの「自動車の故障診断に関連するプログラマーになりたての方が参照するとよさそうな情報」の読み方
@kazuo_reve「AUTOSARのClassic PlatformとAdaptive PlatformにおけるDiagnosticsの違いを整理」で慌てて
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
文書履歴
ver. 0.01 初稿 20220210