ISO/IEC JTC 1/SC 25/WG 1
N 952
Date: 2001-01-24
ISO/IEC JTC 1/SC 25/WG 1
Interconnection of Information Technology Equipment
Home Electronic System
Title:
Information technology — Interconnection of information
technology equipment — Home electronic system — Guidelines
for product interoperability — Project outline
Source:
ISO/IEC JTC 1/SC 25/WG 1
Project:
Project: 25.01.07.01
Status:
Working document
Requested Action:
Distribute
Distribution:
ISO/IEC JTC 1/SC 25/WG 1
ISO/IEC JTC 1/SC 25/WG 1 N 952
Guidelines for product interoperability — Project Outline
1) Project Goals
a) Specify the requirements for interoperability within Home Electronic System.
b) Specify how application-level interoperability can be achieved between logical entities.
c) Specify multiple levels of conformance:
i)
Conformance that assures interoperability within a system.
ii)
Conformance that assures interoperability between systems.
d) Specify a common framework that shall be used to describe application programming interfaces and data structures.
i)
Design that framework in such a way that it may take advantage of transformation technologies that are becoming available.
e) Develop several example Application Models that use the above mechanisms.
i)
Allows validation of A, B and D above.
ii)
Provides examples of how to apply A, B and D.
2) Project working party
a) Project editor: Ron Ambrosio
b) Working party members:
Ron Ambrosio, US
François Borghese → Claude Françon (?), France
Peter Colebrook, UK
Andreas Kinne, Germany (limited time available)
Norimasa Minami, Japan
Stephen Pattenden, UK
Tom Schmidt, US
3) Plan
a) Develop a 3 part standard
i)
Part 1: Introduction
(1) Provide an overview and definition of what Interoperability is.
(2) Discuss and specify interoperability requirements in general terms.
(3) Establish terminology.
ii)
Part 2: Taxonomy and lexicon
(1) Define the taxonomy framework that will be used to analyze systems.
(2) Define the lexicon that will be used to precisely describe interoperable application systems.
iii) Part 3: Application models
(1) Using the lexicon from Part2, develop several initial application models
Page 1 of 3
ISO/IEC JTC 1/SC 25/WG 1 N 952
(a) These will help validate the frameworks in Part 2.
(b) They will provide examples of how to develop application models.
b) Definitions/explanations
i)
Lexicon
(1) Using the analogy of human languages, in order to translate between any two languages
we need to understand both the semantics (in our case, this will be the application models which we'll define in part 3 of the standard) and the lexical elements - the nouns (objects) and verbs (actions) of the language.
An obvious part of the lexicon is a set of common data-type primitives (the "nouns"). A
more challenging part of the lexicon is a set of common action primitives (the "verbs").
We must be careful to maintain separation between the concept of "action primitives" and
the actual implementation of how to invoke those actions. For example, Convergence uses put/get functions to implement a "data driven" programming model. Don't consider
put/get to be action primitives in this case. Rather, they are a programming mechanism
used to invoke actions by setting certain variables with certain values. It is those variables and the set of values they can contain which define the actions that are taken. The
same actions might be invoked in a different system by performing a function call. Both
systems can implement the same lexicon ... they simply use different invocation mechanisms.
In Convergence, the lexicon has been merged into the application models. This is possible because there is agreement between all parties to modify their existing systems to
conform to the new unified application models.
We should not assume that same level of agreement exists for adopting our new ISO/IEC
standard. We need to strive for a more automatic translation between existing systems.
To achieve that, we need to define a lexicon that all application models can be described
with. Without that, we don’t have a chance of automatically mapping one system's applications into another system's.
c) Taxonomy
i)
Our hope is that having an explicit taxonomy framework will make the job of analyzing existing Systems a lot easier.
(1) We don't want to do a complete taxonomy of any existing System, but instead will choose
a small set of example applications/services (such as lighting or HVAC) and describe the
Elements of each System that apply to those applications/services, giving us a common
partial-taxonomy for each System we analyze.
(a) The purpose would be to validate the taxonomy approach, and to gain some direct
experience in how these taxonomies can help implement interoperation between
Systems.
(2) At most we will only create partial taxonomies of about 4 Systems: LonWorks, HomePnP,
Convergence, VHN (and EchoNet, if Norimasa would agree to do that work).
ii)
How does this taxonomy framework relate to the Lexicon?
(1) The Lexicon will grow from the set of taxonomy items we identify as common to most/all
systems: Value Type Primitives, Element/Sub-Element Names and Descriptors, Functional Descriptors, I/O Descriptors, and I/O-Functional Descriptor Lists.
(a) In effect, the Lexicon will simply be one instantiation of the taxonomy framework, but
one that represents the items we deem to be either common across Systems, or important enough to include for whatever other reason. Also, the Lexicon does not describe a coherent System, but rather serves as a collection of specific taxonomy
framework items that we define for describing Systems ... it is a collection of specific
actions, objects, data types, etc. that make up our taxonomy "language".
Page 2 of 3
ISO/IEC JTC 1/SC 25/WG 1 N 952
iii) The ultimate goal is to give manufacturers a process they can use for defining there own interoperability with the International Interoperability Standard.
(1) We are not in the business of doing complete taxonomies of all Systems, nor of defining
specific interoperability approaches for existing Systems. To the extent that we do create
partial-taxonomies and work through interoperability experiments on existing Systems, it
is only for the purpose of validating our taxonomy framework, defining a Lexicon, and defining processes that will be part of the Standard.
4) Schedule
a) The initial Committee Draft of Part 1 has been circulated for comment.
i)
Will be reviewed at Boston meeting.
b) Target for first working draft of Part 2 is May, 2001
i)
Would like to have a first Committee Draft ready for circulation for comments to SC 25 by the
plenary meeting date.
c) Part 3 will be started after Part 2 is circulated for comment.
i)
Will use the existing HES Application Model technical reports as a starting point.
ii)
Assuming the Part 2 schedule holds, target would be to have a first working draft by the winter 2002 WG 1 meeting.
Page 3 of 3