} Month::=IA5String{"January","February",..., "December"} DayInMonth::=INTEGER SIZE (1..3 CAS/callnfoRefuse(INTEGER(0..1) Fig. 7.26 Abstract service primitives with typed parameters (ASN.1 types) The figure shows two forms: in the upper version, the meaning of the data is retained by retaining the identifiers from the symbolic specification. However, identifiers are only for human interpretation and therefore of no concern in creating and interpreting messages. Therefore, in the lower version all identifiers are omit- 7 Concepts and Notations for Process Control Systems Modelling ted. This is the version that is required by the message handler in the corresponding protocol element (see Sect. 5.4.3). The specification refinements from the symbolic to the typed form comprise (in this case) the following changes: Assigning ASN.1-types to all parameters, e.g. representing typeOfInfo with an INTEGER. Substituting value references with data values, e.g. representing the value refer- ence time of typeOfInfo with the integer value 0. Assigning tags to CHOICE types. Deciding how to represent SET. We could have retained the SET types by assigning tags to the parameters. Here, however, the decision was to substitute the SET types with the type SEQUENCE. Insert some formatting data, see the type assignment for Time and Date. All ASPs that belong to the same operation (here CAS/calInfo) are provided in an operation specification for CAS/calInfo. This specification is just one of sev- eral operation specifications within the primitive service specification for CAS, see Fig. 7.25. Finally, we must also provide type information for primitive type, opera- tion name and service name. Type information for primitive type and operation name is normally common for all operations within a primitive service, and is, in that case, specified in the primitive service specification, see Fig. 7.27. Primitive service specification for CAS: PrimType ::=ENUMERATED{request(0), confirm(1), refuse(2),order(3),offer(4), invite(6),replni(7),repCnf(8