FprEN 50090-6-2:2021
(Main)Home and Building Electronic Systems (HBES)- Part 6-2 IoT Semantic Ontology model description
Home and Building Electronic Systems (HBES)- Part 6-2 IoT Semantic Ontology model description
This document defines the HBES Information Model and a corresponding data exchange format for the Home and Building HBES Open Communication System.
Elektrische Systemtechnik für Heim und Gebäude (ESHG) - Teil 6-2: Beschreibung des IoT semantischen Ontologiemodells
Systèmes électroniques pour les foyers domestiques et les bâtiments (HBES) - Partie 6-2: Description du modèle ontologie sémantique loT
Le présent document définit le modèle d'informations HBES et un format d'échange de données 47 correspondant pour le Système ouvert de communication pour les foyers domestiques et les 48 bâtiments HBES.
Stanovanjski in stavbni elektronski sistemi (HBES) - 6-2. del: Semantični opis ontološkega modela
General Information
Standards Content (sample)
SLOVENSKI STANDARD
oSIST prEN 50090-6-2:2020
01-maj-2020
Stanovanjski in stavbni elektronski sistemi (HBES) - 6-2. del: Semantični opis
ontološkega modela
Home and Building Electronic Systems (HBES)- Part 6-2 IoT Semantic
Ontology_Model_Description
Systèmes électroniques pour les foyers domestiques et les bâtiments (HBES) Partie 6-2:
Semantic Ontology Model Description pour l’internet des objetsTa slovenski standard je istoveten z: prEN 50090-6-2
ICS:
35.240.67 Uporabniške rešitve IT v IT applications in building
gradbeništvu and construction industry
97.120 Avtomatske krmilne naprave Automatic controls for
za dom household use
oSIST prEN 50090-6-2:2020 en,fr
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------oSIST prEN 50090-6-2:2020
---------------------- Page: 2 ----------------------
oSIST prEN 50090-6-2:2020
EUROPEAN STANDARD DRAFT
prEN 50090-6-2
NORME EUROPÉENNE
EUROPÄISCHE NORM
March 2020
ICS
English Version
Home and Building Electronic Systems (HBES)- Part 6-2 IoT
Semantic Ontology_Model_Description
To be completed To be completed
This draft European Standard is submitted to CENELEC members for enquiry.
Deadline for CENELEC: 2020-06-12.
It has been drawn up by CLC/TC 205.
If this draft becomes a European Standard, CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which
stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
This draft European Standard was established by CENELEC in three official versions (English, French, German).
A version in any other language made by translation under the responsibility of a CENELEC member into its own language and notified to
the CEN-CENELEC Management Centre has the same status as the official versions.CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the
Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to
provide supporting documentation.Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without notice and
shall not be referred to as a European Standard.European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2020 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Project: 66523 Ref. No. prEN 50090-6-2 E---------------------- Page: 3 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020
1 Contents Page
2 European foreword ............................................................................................................................................ 3
3 1 Scope...................................................................................................................................................... 4
4 2 Normative references ........................................................................................................................... 4
5 3 Terms, definitions and abbreviations ................................................................................................. 4
6 3.1 Terms and definitions ........................................................................................................................... 4
7 3.2 Abbreviations ........................................................................................................................................ 4
8 4 HBES Information Model (Ontology) ................................................................................................... 4
9 4.1 Motivation .............................................................................................................................................. 4
10 4.2 Introduction ........................................................................................................................................... 5
11 5 Location Model ...................................................................................................................................... 6
12 5.1 Introduction ........................................................................................................................................... 6
13 5.2 Classes and Relations .......................................................................................................................... 7
14 5.2.1 Introduction ........................................................................................................................................... 7
15 5.2.2 Classes ................................................................................................................................................... 9
16 5.2.3 Relations .............................................................................................................................................. 14
17 6 Device Model ....................................................................................................................................... 16
18 7 Point Model .......................................................................................................................................... 17
19 8 Tagging Model ..................................................................................................................................... 27
20 8.1 Introduction ......................................................................................................................................... 27
21 8.2 Entities and Relations......................................................................................................................... 28
22 Bibliography ..................................................................................................................................................... 31
---------------------- Page: 4 ----------------------oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020 (E)
24 European foreword
25 This document (prEN 50090-6-2:2020) has been prepared by CLC/TC 205 “Home and Building
26 Electronic Systems (HBES)”.27 This document is currently submitted to the Enquiry.
28 The following dates are proposed:
• latest date by which the existence of this (doa) dor + 6 months
document has to be announced at national
level
• latest date by which this document has to be (dop) dor + 12 months
implemented at national level by publication of
an identical national standard or by
endorsement
• latest date by which the national standards (dow) dor + 36 months
conflicting with this document have to be (to be confirmed or
withdrawn modified when voting)
---------------------- Page: 5 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020
29 1 Scope
30 This document defines the HBES Information Model and a corresponding data exchange format for
31 the Home and Building HBES Open Communication System.32 2 Normative references
33 The following documents are referred to in the text in such a way that some or all of their content
34 constitutes requirements of this document. For dated references, only the edition cited applies. For
35 undated references, the latest edition of the referenced document (including any amendments)
36 applies.37 EN 50090-1, Home and Building Electronic Systems (HBES) - Part 1: Standardization structure
38 3 Terms, definitions and abbreviations39 3.1 Terms and definitions
40 For the purposes of this document, the terms and definitions given in EN 50090-1 apply.
41 ISO and IEC maintain terminological databases for use in standardization at the following addresses:
42 • IEC Electropedia: available at http://www.electropedia.org/43 • ISO Online browsing platform: available at http://www.iso.org/obp
44 3.2 Abbreviations
45 For the purposes of this document, the following abbreviations apply.
IoT Internet of Things
HBES Home and Building Electronic Systems
46 4 HBES Information Model (Ontology)
47 4.1 Motivation
48 The current HBES model/ data information is based on XML, is managed by the KNX Association and
49 has its corresponding versioning. Project/ product data exported by existing HBES management
50 clients are in line with this XML schema.51 Even if XML itself is a well-known and widespread format, it has its drawbacks in the context of
52 sharing model/ project data information with external clients using this data. HBES management
53 clients use the XML schema mainly to define the corresponding data structures to store/ export
54 project and product data. Consequently, the XML schema is always updated when a new
55 management client version is published, when new project and/or product features demand also a
56 change of the data structures. This requires always a synchronization with the external clients to
57 announce new XML schema versions.58 The aim and motivation is to define a HBES Information Model and a corresponding data exchange
59 format:60 — The model expresses only the current - by external clients requested - information
61 — The model can be also easily updated62 — The exported data uses a widely used data exchange format, which should also be readable by
63 humans, means they are a text based.---------------------- Page: 6 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020 (E)
64 This model and data exchange format is more stable, compared to the frequent HBES management
65 client evolution.66 — The HBES Information Model will be available as ontology in one or more formats, such as turtle
67 files.68 — The data exported by HBES management clients will be available as linked data, such as JSON-
69 LD files.70 The HBES IoT protocol suite shall support semantic information, both for runtime as well as for
71 configuration.72 This information shall be brought to the system components in a data driven way, by the HBES
73 management clients software and possible other sources. It shall thus build on the information
74 provided by the HBES management clients user, to avoid having to be entered again in the 3 Part
75 Client configuration.76 The semantic information shall comply with the HBES standard and be available as public
77 information. Technically this information will be available as linked data, expressed with triples.
78 The use of semantics itself allows to formalize, restrict, and verify the usage of HBES subjects to
79 describe entities, relationships, and tags (entities have some relationship predicate to some other
80 entities— essentially a directed edge in a graph).81 This simple (triple) structure enables the succinct and elegant composition of large, interconnected
82 structures of facility (building) subsystems.83 4.2 Introduction
84 The HBES system is designed for direct exchange of information (i.e. communication) between
85 networked devices controlling applications in and around buildings. See Figure 1.
87 Figure 1 — HBES environment88 These different aspects of the HBES environment are reflected by an individual “model” for Location,
89 Devices, Applications as well as the Communication for exchange of control information. All individual
90 model parts together form the entire HBES IoT Information Model as a single ontology. Ontologies are
91 a structured way to describe the meaning of data and should not be mixed up with common data
92 model structures. Ontologies work with the term “concepts” to describe things that have a real-world
93 commonality. In the ontology itself such things are expressed technically as ontology classes.
94 For simplification the term model will be used further down. Figure 2 describes the HBES Information
95 Model parts. It contains the following:96 — Equipment (devices and other physical assets)
97 — Application Software (software to run the intended system behaviour)
---------------------- Page: 7 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020
98 — Point (interface to interact with data points mainly provided by devices
99 — Aspects (grouped points that identify a specific view/perspective to the system)
100 — Location (structural building elements)101
102 Figure 2 — HBES Information Model
103 The HBES Information Model builds upon other work in several ways.
104 It is inspired by the BRICK concept to model Points, Equipment and Context and their relationships.
105 It can be extended with tagging vocabulary such as Haystack.106 In addition, it uses the location concepts from IFC and allows a semantic representation to utilize its
107 flexibility and extensibility. For this the HBES Information Model supports an explicit mapping to IFC
108 with a so called “bridging” ontology. The HBES-IFC mapping, respectively the bridging is available as
109 electronic turtle file under https://schema.knxiot.org/ontology/owl-mapping/knx-ifc-mapping.
110 The current HBES Information Model does not consider other aspects of a HBES installation such as
111 for instance topology or device models.112 5 Location Model
113 5.1 Introduction
114 The Location model wishes to address the following requirements.
115 — Bridging to BIM
116 Many concepts of the Location model match concepts provided by the Industry Foundation Class
117 Ontology (ifcowl) that has been created to work with BIM models. In particular, Building, Floor and
118 Space map to IfcBuilding, IfcBuildingStorey and IfcSpace and thus make bridging to a BIM model
119 quite easy.120 — Alternate hierarchies
---------------------- Page: 8 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020 (E)
121 The common superclass Location of HBES IoT Information Model allows specifying an alternate
122 location hierarchy or not strictly sticking to the usual hierarchy, should someone - for some reason –
123 want to do so.124 EXAMPLE 1 A HBES IoT Information Model element Room can be associated directly with a Building (rather
125 than with a Floor, as usual) semantically strongly expressed via object property “hasRoom” or semantically
126 weakly expressed via the object property “hasSubLocation”, without violating any constraints specified by the
127 Location model.128 — Extensibility
129 The concept Space represents a generic location inside a building. Therefore, it can also be used to
130 define types of Locations that do not fit directly into the fabric of the existing Location model classes.
131 This can either be achieved by defining (in an extension of the current HBES Information Model)
132 additional properties or by defining new subclasses of Space that are better suited for the respective
133 purpose.134 EXAMPLE 2 If it is wanted to model a wing as a part of a building, then a class Wing with specific wing
135 properties may be added.136 5.2 Classes and Relations
137 5.2.1 Introduction
138 This section contains a formalized description of the location model as shown in the Figure 3 below.
139 — The blue box denotes the topmost generic Location, from which all subclasses are derived.
140 — Green boxes denote HBES Information Model concepts that are mapped to IFC concepts with
141 the HBES- IFC mapping ontology.142 — White boxes with annotation “subClassOf” define specific (child) Location classes, white boxes
143 without this annotation describe concepts, independent from the concept Location.
144 — Red dotted lines and their direction describe relationships between classes.
---------------------- Page: 9 ----------------------oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020
145
146 Figure 3 — Location Model
147 Ontology classes or their relationships have many properties. Only the main ontology classes and
148 their main properties are described here.149 Not all relationship properties (such as being “functional”), their property domain/ range and possible
150 available inverse properties to this relationship are enumerated in the below lists. Also, if a class
151 supports an explicit name and/or description is not mentioned hereunder.152 For these details, please refer to the HBES IoT Information Model under
153 https://schema.knxiot.org/ontology/full.
---------------------- Page: 10 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020 (E)
154 5.2.2 Classes
155 Table 1 — Classes of the Location Model
Class Definition
Location Description
A Location is a physical named geographical place (such as “Lake side
meeting room”, “Oskar's office”, “The 5th floor”, “Mountain view dwelling”
etc.) that is used to identify a point, an area or room, inside or outside of a
Building.
Main Properties
— hasSubLocation
— hasAdjacentLocation
— hasLocationType
— hasAddress
— hasPerimeter
— hasFunction
— hasDevice
Sub Class of
Disjoint With
— all root classes of HBES IoT Model
Notes
The class Location can be used as a bridging class to other ontologies
(e.g. to the Point model, see Clause 1.5).
Site Description
A Site represents a collection of Buildings and grounds that belong to a
given institution.
Main Properties
— hasBuilding
— hasSiteSegment
Sub Class of
Location
Disjoint With
— Building, Floor, Space
Notes
The concept Site can be mapped to an IFC Site.
---------------------- Page: 11 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020
Class Definition
SiteSegment Description
A SiteSegment is a part of a ground, land or of a campus. It subdivides a
Site.
Main Properties
Sub Class of
Site
Disjoint With
Notes
The concept SiteSegment can be mapped to an IFC Site.
Building Description
A Building represents a whole building. A real-world building hosts several
other real-world elements such as stacked floors or spaces or rooms, in
ontology terms this would a Room, Floor, Space, RoomSegment.
Main Properties
— hasFloor
— hasRoom
— hasRoomSegment
— hasSpace
Sub Class of
Location
Disjoint With
— Site, Floor, Space
Notes
For a Building, it might also make sense to specify a LocationType and/or
an Address.
The concept Building can be mapped to the IFC concept IfcBuilding.
---------------------- Page: 12 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020 (E)
Class Definition
Floor Description
A Floor is a level or plane concept in a building. A Floor is separating a
Building into horizontal spaces.
A Floor can have Space assigned, in particular a Room or a
RoomSegment.
Main Properties
— hasLowerFloor
— hasUpperFloor
— hasRoom
— hasRoomSegment
— hasSpace
Sub Class of
Location
Disjoint With
— Site, Building, Space
Notes
For a Floor, it might make sense to specify a LocationType, while a postal
Address is usually already specified for the Building containing the Floor.
The concept Floor can be mapped to the IFC concept IfcBuildingStorey.
Space Description
A Space represents any kind of physical space that belongs to a Building
(inside or outside). Space can be also used on its own as a generic
location. Furthermore, it can be subdivided into locations of type Space or
any of its subclasses (Room, RoomSegment).
Main Properties
— hasRoom
— hasRoomSegment
— hasSpace
Sub Class of
Location
Disjoint With
— Site, Building, Floor
Notes
The concept Space can be mapped to the IFC concept IfcSpace.
---------------------- Page: 13 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020
Class Definition
Room Description
A Room is a Space in a Building that is delimited by walls, ceilings, floors,
windows and doors.
A Room can be subdivided into locations of type RoomSegment.
A Room may also be part of another Room.
Main Properties
— hasRoom
— hasRoomSegment
— hasRoomType
Sub Class of
Space
Disjoint With
— RoomSegment
Notes
The concept Room can be mapped to the IFC concept IfcSpace.
RoomSegment Description
A RoomSegment is an indoor space that represents a subdivision of a
Room.
Besides that, a RoomSegment may also be part of any other kind of
Space, e.g. a Building or a Floor.
A RoomSegment can be further subdivided into locations of type
RoomSegment.
Main Properties
— hasRoomSegment
— hasRoomType
Sub Class of
Space
Disjoint With
— Room
Notes
The concept RoomSegment can be mapped to the IFC concept IfcSpace.
---------------------- Page: 14 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020 (E)
Class Definition
Address Description
An Address is represented by an external ontology object of type
vcard:Address, which has data properties such as country-name, locality
(city), street-address.
Address can be assigned to any location via hasAddress property, but
preferably to a Site or a Building.
Main Properties
Sub Class of
Disjoint With
— all root classes of HBES IoT Model
Notes
PerimeterType Description
The PerimeterType denotes if a given location is inside or outside of a
Location, preferably with respect to a Building.
Outside is preferably used to a Site or a Building, while inside can be used
for a Room, RoomSegment, Floor and other.
Main Properties
Sub Class of
Property
Disjoint With
— all subclasses of class Property
Notes
PerimeterType is a class with two individuals (outside, inside).
Examples for such outside locations are “West Facade” or “Rooftop”; it is
obvious that they require some association with a particular building and
probably also (in case of a facade) a specification of an outside direction
(e.g. “West”).
Hence this further object properties/ attributes are required to specify the
concept of being “inside” or “outside” of something more precisely, such as
the above-mentioned geographical direction of something else that is
interpreted as outside.
---------------------- Page: 15 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020
Class Definition
LocationType Description
LocationType defines several subclasses, each of it responsible for its own
usage concept.
— the concept room types with usage enumeration values “kitchen,
bath, …”
— the concept other types usage enumeration values “garden,
garage, parking place, …”).
This kind of attribute is preferably associated with locations of type Site or
Building but can also be used for any other kind of location, e.g. Space,
Room or RoomSegment.
The LocationType subclass RoomTypes defines the intended usage of a
Location and is preferably associated with locations of type Room or
RoomSegment but can be also used for any other kind of location, e.g.
Building or even Site.
The LocationType subclass OtherTypes defines the intended usage of a
Location and is preferably associated with locations of type Site.
Main Properties
Sub Class of
Property
Disjoint With
— all subclasses of Property
Notes
LocationType, subclass RoomTypes is an open enumeration and can be
extended.
LocationType, subclass OtherTypes is an open enumeration and can be
extended.
156 5.2.3 Relations
157 The class relationship describes the mandatory object relation, if given the second relationship (in
158 italic) describes the corresponding inverse relation. Domain/ Range is described for the mandatory
159 relation (usually domain and range are interchanged here). See Table 2.160 Table 2 — Relations of the Location Model
Class Definition Domain Range
Relationship
hasSubLocation / Generically expressed semantic relationship :Location :Location
isSubLocationOf to any subclass of a Location, e.g. a room as
sub-location of a floor.
Sub Property of
RefersTo (Transitive)
hasAdjacentLocatio Relationship between two Locations that :Location :Location
n share a common interface such as a wall or
door, but do not intersect.
Sub Property of
hasAdjacency
---------------------- Page: 16 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020 (E)
Class Definition Domain Range
Relationship
hasPerimeter / Relationship of a Location to express the :Location :Perimeter
isPerimeterOf relationship if this Location is inside or Type
outside.
Mainly used in conjunction with buildings, see
also class Building.
Sub Property of
hasLocationType / Generically expressed semantic relationship :Location :LocationT
isLocationTypeOf of a Location to express how the Location is ypebeing used.
Sub Property of
hasRoomType / Strongly expressed semantic relationship of a :Room :RoomTyp
isRoomTypeOf Room or RoomSegment on how the Room or or:RoomS e
RoomSegment is used. egment
The relationship is a subproperty of
hasLocationType.
Sub Property of
hasLocationType
vcard:hasAddress Relationship of a Location to its Address. :Location vcard:Add
ress
Sub Property of
hasBuilding / Strongly expressed semantic relationship to a :Site :Building
isBuildingOf Building contained in a Site.
The relationship is a subproperty of
hasSubLocation.
Sub Property of
hasSubLocation
hasFloor / Strongly expressed semantic relationship to a :Builidng :Floor
isFloorOf
Floor contained in a Location.
The relationship is a subproperty of
hasSubLocation.
Sub Property of
hasSubLocation
hasUpperFloor / Relationship from one Floor to another Floor. :Floor :Floor
isUpperFloorOf
The relationship is a subproperty of
hasProximity.
Sub Property of
hasProximity
---------------------- Page: 17 ----------------------
oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020
Class Definition Domain Range
Relationship
hasRoom / Strongly expressed semantic relationship to a :Building :Room
isRoomOf Room contained in a Location. or:Space
The relationship is a subproperty of
hasSubLocation.
Sub Property of
hasSubLocation
hasRoomSegment / Strongly expressed semantic relationship to a :Room :RoomSeg
isRoomSegmentOf RoomSegment contained in a Room or or:RoomS ment
RoomSegment. egment
The relationship is a subproperty of
hasSubLocation.
Sub Property of
hasSubLocation
hasSpace / Strongly expressed semantic relationship to a :Building :Space
isSpaceOf Space contained in a Location. or:Space
The relationship is a subproperty of
hasSubLocation.
Sub Property of
hasSubLocation
hasSiteSegment / Strongly expressed semantic relationship to a :Site :SiteSegm
isSiteSegmentOf
SiteSegment contained in a Site. ent
The relationship is a subproperty of
hasSubLocation.
Sub Property of
hasSubLocation
161 6 Device Model
162 In the Device model, the parts of the devices are identified that are required in a HBES IoT
163 environment such as semantic export data and data accessible via the KNX IoT interfaces.
164 These identified elements need to be part of the HBES IoT Model.165 As already mentioned in the chapter introduction of HBES IoT Information Model; devices are the
166 most important elements of the entire model. Devices provide Points, which are the principal data
167 interfaces of the entire installation. With their links to other Points, they build up the entire intended
168 Application Communication of the installation.169 As an important note here, the above-mentioned links between the Points do not establish
170 automatically an Application Communication in a unicast (one to one point) or multicast (one to many
171 point) way. Technically, in HBES this is achieved by grouping (known as linking) the intended points
172 with a unique HBES group address “link”. The concept corresponding to this “link” is referred to as a
173 FunctionPoint. This is referred to as group communication.174 In a simplified view, a device consists of two main parts.
175 1) Device hardware (such as a PCB, the device housing or “hardwired” IO input/output terminals)
---------------------- Page: 18 ----------------------oSIST prEN 50090-6-2:2020
prEN 50090-6-2:2020 (E)
176 2) Application Software (provides “logical” interface IOs and Parameter values controlling the IO
177 behaviour at runtime). In the end, it is the task of the application software to handle all IO
178 requests at runtime.179 From the perspective of logical interworking at runtime, inputs/outputs for process communication,
180 parameter and diagnostic Points exist (see the brown boxes below in Figure 4).
181 A Point may represent information of the device itself (e.g. life check signalling, power on LED) or
182 data related to the intended automation functionality.183 This document uses the term Point as an umbrella for data that can be accessed from outside of the
184 device, for instance to interact with other Points from other devices.185 The device depicted below hosts an Application Software represented by a blue box that contains
186 physical and logical inputs and outputs.187 These in/outputs could belong to a dedicated device channel with the related hardware IOs (for
188 example n- dimming channel - terminals in a n- fold dimming actuator device). In this case each
189 channel is also representing a specific Functional Block, here a FB “Dimming Actuator” with its
190 mandatory/ optional in/outputs, parameter or diagnostic Points.191 a) Parameter Points are available for Application Software configuration
192 b) Diagnostic Points are available for monitoring purposes.
193 c) Input
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.