KNX Interworking Information Model

[LosWochos]

Hallo zusammen,

ich beschäftige mich gerade damit, einen Überblick über verschiedene Kommunikationssysteme der Gebäudeautomation zu bekommen. Als Informatiker versuche ich dabei u.a. zu verstehen, welches Informationsmodell das jeweilige System implementiert (OSI-Ebene 7). Bei KNX scheint dieses durch das sog. Interworking Model (Abschnitt 3-7-1 des Standards) definiert zu werden. Leider wird im Standard allerdings kein Versuch unternommen, das Informationsmodell in Form von UML darzustellen. Ich habe mal versucht, ein solches UML-Model zu erstellen. Anbei das Model, welches ich in zwei Abstraktionsebenen (Meta-Model + Model) aufgeteilt habe.

Von folgenden Prämissen bin ich dabei ausgegangen:

• Zentrales Element der verteilten Datenhaltung ist der DataPoint. Er basiert auf einem DataPointType, der vor allem festlegt, wie die Daten in einem KNX-Frame repräsentiert werden. Konkrete DataPointTypes sind z.B. DPT_Bool, DPT_State. Von diesen konkreten DPT existieren sehr viele.
• DataPoints werden in Funktionalen Blöcken, den sog. InformationObjects organisiert. Ein DataPoint kann im Bezug zu einem InformationObject ein Input, Output oder Parameter sein. Konkrete Realisierung eines InformationObjects wie z.B. SCLO (System Clock) oder LSAB (Light Switching Actuator Basic) legen genau fest, welche DataPoints verpflichtend/optional in diesem Funktionsblock vorzufinden sind. Auch von diesen konkreten InformationObjects existieren viele, sie können aber erweitert werden.
• Ein Device besitzt eine physikalische Adresse und eine Seriennummer. Ein Device besitzt mindestens einen Funktionsblock.
• GroupObjects sind das Rückgrat der Datenübertragung über das Netz. Durch GroupObjects werden DataPoints des selben DataPointTypes miteinander verbunden. Durch eine Änderung an einem Output-DataPoint in einem Device werden die Daten dann an die Input-DataPoints übertragen.

Habe ich das alles soweit richtig verstanden?

Viele Grüße,

Alexander Stuckenholz

[S. De Bruyne]

Functional Blocks and Datapoints are the model. Group Object are one possible, most common realisation of Datapoints. So, it should be "GruppenAdressen sind das Rückgrat der Datenübertragung über das Netz. Durch GruppenAdressen werden GroupObjects" ... So, the DataPoint belongs to the meta-model, not to the Model.

[LosWochos]

Hallo,

thank you for your quick response. Unfortunately, I do not quite understand what you want to say.

From my understanding Group Objects are not a realisation of Datapoints. KNX Standard says that "The standardized containers for Datapoints are Group Objects and Interface Objects" and later "a node’s Group objects constitute a flat set of Datapoints". Isnt a Group Object rather a means to bind multiple DataPoints together with one common Group Address, then?

Your comment on the DataPoint rather beeing on the level of the meta-model is comprehensible. I changed that. Please find the adapted model attached.

Best regards,

Alex

[S. De Bruyne]

I will come back later ... meanwhile, where did you find the KNX Standard excerpts that you quote above? I know it pretty well, but I cannot recall where this is expressed in this way.

[LosWochos]

I was citing the KNX System Specification v 3.0 - Part 3-1 on Architecture:
Page 6 (Applications, Interworking and Binding): "The standardized containers for these Datapoints are
Group Objects and Interface Object Properties."
Page 14 (Properties of Interface Objects as Datapoints): "Whereas a node’s Group objects constitute a flat set of Datapoints..."

[Klaus Gütter]

I know it pretty well

[S. De Bruyne]

So, for all clarity, Datapoints are a model and Group Objects are the realization. That quoted remarkable expression does not mean that Group Objects are contained in Datapoints or vice versa. Other realisations of Datapoints are Properties of Interface Objects (not entire Interface Objects, only Properties of them. In LTE-Mode that is even very explicit.)
The "flat set" means that - opposite to the Properties of an Interface Object - the Group Objects do not have a superordinate structure and are basically a flat list. (Yes, there are Channels, but that is only mainly a user interface aspect in ETS or a binding aspect in E-Mode).

[EugenDo]

Wird das UML veröffentlicht, wenn es dann geklärt ist?

[S. De Bruyne]

Why not, but it is the first time that I hear about this need.
° What is the difference between InformationObject and FunctionalBlock?
° Meanwhile, we also see Status and Diagnostic Values as additional types of Datapoints, next to Input, Output and Parameter.
° And of course, (array) Elements of Property Values can also be the implementation of a Datapoint.

[LosWochos]

Hello again,

as a result to your qualified comments I reworked my UML model from the ground. I found a really good book, that made things a lot more clear to me (Industrial Communication Technology Handbook). I now understand that a Group Object (or better the value of it) is indeed an instance of a Data Point. A device can either have a flat list of such Group Objects or provide Properties as part of an Interface Object which realizes a functional block.

Are you ok with this now? I attached the adapted UML-model again.

Best regards...

P.s.: I am actually astonished that nobody tried to create a UML-model of the interworking model so far and that such a model is also not part of the official specification. Dosn't such a formal model make things much more clear in comparison to pages and pages of written text?

[S. De Bruyne]

Why do you see the Group Object Value and the Property Value as instance of the Datapoint, and not the Group Object and the Property?
A Group Object may be an implementation of a Datapoint, but that does not mean that its data structure and further functionality is limited to that Datapoint.

Also note that it is not an either/or story: a device may have any combination of Interface Objects and Group Objects.

I do not know whether UML is an ISO or IEC standard or whether it can be used in a normative way in such standards.