ISO/IEC 9506-2:1990/Cor 1:1995

Industrial automation systems — Manufacturing Message Specification — Part 2: Protocol specification — Technical Corrigendum 1

Systèmes d'automatisation industrielle — Spécification de messagerie industrielle — Partie 2: Spécification de protocole — Rectificatif technique 1

General Information

• Status: Withdrawn
• Publication Date: 29-Nov-1995
• Withdrawal Date: 29-Nov-1995
• ICS: 25.040.40 - Industrial process measurement and control
• Technical Committee: ISO/TC 184/SC 5 - Interoperability, integration, and architectures for enterprise systems and automation applications
• Drafting Committee: ISO/TC 184/SC 5 - Interoperability, integration, and architectures for enterprise systems and automation applications
• Current Stage: 9599 - Withdrawal of International Standard
• Completion Date: 31-Aug-2000

Relations

• Revised: ISO 9506-2:2000 - Industrial automation systems — Manufacturing Message Specification — Part 2: Protocol specification
• Effective Date: 15-Apr-2008
• Corrects: ISO/IEC 9506-2:1990 - Industrial automation systems — Manufacturing Message Specification — Part 2: Protocol specification
• Effective Date: 06-Jun-2022
• Child: ISO/IEC 9506-2:1990 - Industrial automation systems — Manufacturing Message Specification — Part 2: Protocol specification
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL STANDARD ISO/IEC 9506-2:1990
TECHNICAL CORRIGENDUM 1
Published 1995-12-15
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION- MExDYHAPODHAfl OPI-AHM3AUMFl l-l0 CTAH~APTM3ALWW ORGANISATION INTERNATIONALE DE NORMALISATION
INTERNATIONAL ELECTROTECHNICAL COMMISSION-MExJlYHAPOPHAR 3JlEKTPOTEXHVlqECKAFl KOMklCCVlR- COMMISSION ~LECTROTECHNIQUE INTERNATIONALE
Manufacturing Message
Industrial automation systems -
Specification -
Part 2:
Protoco I specification
TECHNICAL CORRIGENDUM 1
- Spkcifkation de messagerie industrielle -
Systbmes d’automatisatiun industrielle
Partie 2: Sp6cifkation; de protocole
RECTIFICATIF TECHNIQUE 7
Technical corrigendum 1 to International Standard lSO/IEC 9506-2:1990 was prepared by Technical Committee ISODC 184,
Industrial automation systems and integration, Subcommittee SC 5, Architecture and communications.
Page 72
Subclause 5.14
In the note, lines 1 and 2, change
“this part of this part of”
to
“this part of”
Page 76
Subclause 6.3.1.2
In item a) in the third line change “error class SERVICE” to “error class SERVICE-PREEMPT”.
Ref m No. ISO/IEC 9506-2: 1990/Car. ‘I :1995(E)
KS 25.040.40
Descriptors: automation, automation engineering, manufacturing, messages, computer applications, cOata processing, information
interchange, network interconnection, open systems interconnection, communication procedure, protocols.
63 ISO/IEC 1995
Printed in Switzedand

---------------------- Page: 1 ----------------------
o lSO/IEC
ISO/IEC 9506-2:1990/Cor.l:1995(E)
In item b) in the second line change
“error class SERVICE” to “error class SERVICE-PREEMPT”.
Page 79
Clause 7
Change
{ iso standard 8650 abstract-syntax(2) acse-pdi(1) }
to
( joint-iso-ccitt association-control(2) abstract(l) }
Page 79
Subclause 7.1
Replace the comment line in the Confirmed-RequestPDU production. The protocol in this
subclause should now read:
Confirmed-RequestPDU ::= SEQUENCE {
invokeID Unsigned32,
1istOfModifier SEQUENCE OF Modifier OPTIONAL,
ConfirmedServiceRequest,
[79] CS-Request-Detail OPTIONAL,
--
shall not be transmitted if value is the value
-- of a tagged type derived from NULL
1
Page 20
Subclause 7.1
At the end of the subcl ause, that is, immediately preceding 7.2,
add the fol lowing note
NOTE - The intent of the comment in the Confirmed-RequestPDU production is to preclude the transmission of
the CS-Request-Detail field for all occurrences in the abstract syntax defined in this part of ISO/IEC 9506. This is
done by assigning the NULL type to all the types referenced in the CS-Request-Detail type. (See the type
definitions in 7.5.2 and in clause 19.) MMS Companion Standards may also preclude the transmission of this
field either by defining the appropriate type to be NULL, similarly to the definitions in clause 19, or by selecting a
NULL choice from a CHOICE type.

---------------------- Page: 2 ----------------------
ISO/IEC 9506-2:1990/Cor.l:1995(E)
o lSO/IEC
Page 20
Subclause 7.2
nt line U production.
Ilace the comme in the Unto firmed-PD
Rep
The protoco I in this su bcla use sh.ouI’d ow read:
Unconfirmed-PDU ::= SEQUENCE {
UnconfirmedService,
[79] CS-Unconfirmed-Detail OPTIONAL,
--
shall not be transmitted if value is the value
-- of a tagged type derived from NULL
Page 20
Subclause 7.2
At the end of the subclause, that is immediately preceding 7.3, add the following note:
NOTE - The intent of the comment in the Unconfirmed-PDU production is to preclude the transmission of the
CS-Unconfirmed-Detail field for all occurrences in the abstract syntax defined in this part of lSO/IEC 9506. This is
done by assigning the NULL type to all the types referenced in the CS-Unconfirmed-Detail type. (See the type
definitions in 7.5.3 and in clause 19.) MMS Companion Standards may also preclude the transmission of this
field either by defining the appropriate type to be NULL, similarly to the definitions in clause 19, or by selecting a
NULL choice from a CHOICE type.
Page 20
Subclause 7.3
Replace the comment line in the Confirmed-ResponsePDU production.
The protocol in this subclause should now read:
Confirmed-ResponsePDU ::= SEQUENCE {
invokeID Unsigned32,
ConfirmedServiceResponse,
[79] CS-Response-Detail OPTIONAL,
--
shall not be transmitted if value is the value
-- of a tagged type derived from NULL
Page 20
Subclause 7.3
At the end of the subclause, that is immediately preceding 7.4, add the fol I owing note:
NOTE
- The intent of the comment in the Confirmed-ResponsePDU production i s to preclude the transmission
3

---------------------- Page: 3 ----------------------
o lSO/IEC
ISO/IEC 950602:1990/Cor.l:1995(E)
of the CS-Response-Detail field for all occurrences in the abstract syntax defined in this part of lSO/IEC 9506. This
is done by assigning the NULL type to all the types referenced in the CS-Response-Detail type. (See the type
definitions in 7.5.4 and in clause 19.) MMS Companion Standards may also preclude the transmission of this
field either by defining the appropriate type to be NULL, similarly to the definitions in clause 19, or by selecting a
NULL choice from a CHOICE type.
Page 32
Subclause 7.6.2
91 99
In the definition of Identifier, change “-” t0 (only a single underscore)
-
Page 36
Subclause 8.2
Remove ‘akec’ named bit from the ParameterSupportOptions production.
This production should now read:
ParameterSupportOptions ::= BIT STRING {
strl
(0) I
str2
(1) I
vnam
(2) I
valt
(3) I
vadr
(4) I
vsca
(5) I
tPY (61 I
vlis (7) I
real I
(8)
--
bit 9 reserved for future definition
cei
(10)
I
Page 47
Subclause 10.8
Replace the line
1istOfCapabilities [l] IMPLICIT SEQUENCE OF VisibleString,
with
listofcapabilities [l] IMPLICIT SEQUENCE OF VisibleString OPTIONAL,

---------------------- Page: 4 ----------------------
ISO/lEC 9506-2:199O/Cor.l:1995(E)
o lSO/IEC
Page 48
Subclause 10.8.1
Add the following text at the end of the present text:
If the List Of Capabilities parameter is present in the service request, and the parameter
specifies an empty list, a SEQUENCE OF VisibleString with zero elements shall be transmitted;
if the parameter is not present in the service request, this field shall not be transmitted.
Page 48
Subclause 10.10
Replace the line
1istOfCapabilities [1] IMPLICIT SEQUENCE OF Visiblestring,
with
1istOfCapabilities [l] IMPLICIT SEQUENCE OF VisibleString OPTIONAL,
Page 48
Subclause 10.10.1
Add the following text at the end of the present text:
If the List Of Capabilities parameter is present in the service request, and the parameter
specifies an empty list, a SEQUENCE OF VisibleString with zero elements shall be transmitted;
if the parameter is not present in the service request, this field shall not be transmitted.
Page 59
Subclause 12.4.2
Add an ASN.1 comment following the unsigned choice. That line should now read:
unsigned [6] IMPLICIT INTEGER, -- shall not be negative
Add an ASN.? comment following the bed choice. That line should now read:
bed [13] IMPLICIT INTEGER, -- shall not be negative

---------------------- Page: 5 ----------------------
ISO/IEC 9506=2:1990/Car. 1:1995(E)
o lSO/IEC
Page 62
Subclause 12.4.3
Replace the last line of the protocol with the following:
object-non-existent -- OBJECT-NON-EXISTENT
(10) I
object-value-invalid -- OBJECT-VALUE-INVALID
(11)
Page 80
Subclause 15.8
Replace the comment line in the DefineEventAction-Request production.
The protocol in this subclause should now read:
DefineEventAction-Request ::= SEQUENCE {
eventActionname [0] ObjectName,
1istOfModifier IMPLICIT SEQUENCE
111 OF Modifier OPTIONAL,
confirmedServiceRequest [2] ConfirmedServiceRequest,
cs-extension [79] CS-Request-Detail OPTIONAL,
--
shall not be transmitted if value is the value
-- of a tagged type derived from NULL
>
Page 80
Subclause 15.8.1
At the end of the subclause add the following note:
NOTE - The intent of the comment in the DefineEventAction-Request production is to preclude the transmission
of the CS-Request-Detail field for all occurrences in the abstract syntax defined in this part of lSO/IEC 9506. This
is done by assigning the NULL type to all the types referenced in the CS-Request-Detail type. (See the type
definitions in 7.5.2 and in clause 19.) MMS Companion Standards may also preclude the transmission of this
field either by defining the appropriate type to be NULL, similarly to the definitions in clause 19, or by selecting a
NULL choice from a CHOICE type.
Page 87
Subclause 15.10
Replace the comment line in the GetEventActionAttributes-Response
production. The protocol in this subclause should now read:
GetEventActionAttributes-Response ::= SEQUENCE {
mrnsDeletable
[O] IMPLICIT BOOLEAN DEFAULT FALSE,
1istOfModifier
[l] IMPLICIT SEQUENCE OF Modifier,
confirmedServiceRequest [2] ConfirmedServiceRequest,
cs-extension
[79] CS-Request-Detail OPTIONAL,
--
shall not be transmitted if value is the value
-- of a tagged type derived from NULL
1

---------------------- Page: 6 ----------------------
ISO/lEC 9506-2:1990/Cor.l:1995(E)
o lSO/IEC
Page 87
Subclause 15.10.2
At the end of the subclause add the following explanatory note:
NOTE - The intent of the comment in the GetEventActionAttributes-Response production is to preclude the
transmission of the CS-Response-Detail field for all occurrences in the abstract syntax defined in this part of
ISO/IEC 9506. This is done by assigning the NULL type to all the types referenced in the CS-Response-Detail type.
(See the type definitions in 7.5.2 and in clause 19.) MMS Companion Standards may also preclude the
transmission of this field either by defining the appropriate type to be NULL, similarly to the definitions in clause
19, or by selecting a NULL choice from
...