XML Schema for EBC Information Model

The information model is just a conceptual view of how an EBC architecture can be described. In order to develop a designer or compiler a more tangible form is needed. It seems a XML version of the information model would be very helpful to decouple different tools. Work on a designer could be done independently from work on a visualizer if the two would not rely on any shared code but just on a shared information model expressed in XML.

The following XML document is an example for how the information model could be translated:

<?xml version="1.0" encoding="utf-8"?>
<System name="SomeApp">
  <Board name="MainBoard">
      <Namespace name="root">
        <Namespace name="node.subnode"> <!-- (1) -->
          <Part name="SomePart">
              <OutputPin id="opin" name="SomeName" outputType="string"/>
              <OutputPin id="oadd" outputType="AddRequest" responseType="double"/>
              <InputPin id="iprogress" inputType="double"/>
              <InputPin id="irun" inputType="string[]"/>
      <Part name="AnotherPart">

      <Board name="SubBoard">

    <Pins> <!-- (2) -->
      <InputPin id="irun" name="Run" inputType="string[]"/>

      <ComponentRef id="sp" name="root.node.subnode.SomePart"/> <!-- (3) -->
      <ComponentRef name="AnotherPart"/>
      <ComponentRef name="SubBoard"/>

      <Wire fromPin="MainBoard.irun" toPin="sp.irun"/> <!-- (4) -->
      <Wire fromPin="sp.oadd" toPin="SubBoard.iadd"/> <!-- (5) -->
  • (1): A single namespace element can define a namespace node hierarchy by separating node names with a dot. <Namespace name="r"><Namespace name="s"> is equivalent to <Namespace name="r.s">.
  • (2): Every board needs at least an input pin. Otherwise it cannot interact with its environment. So event the main board here defines a pin.
  • (3): Component references draw together the components to be put on a board. They reference components by full name. In case a board contains several instances of the same component each instance needs a <ComponentReference> of its own - but with a different id. The id can also be used as a shortcut for the component name.
  • (4): Usually wires run from an output pin to an input pin. But the pins of a board need to be connected to pins on its components. That´s where a board´s input pin is connected to a component´s input pin, and a component´s output pin is connected to a board´s output pin. The board itself is doing no processing of messages, so it always needs to connect its pins to some component.
  • (5): In wire definitions pins are referred to by pin id. As the number of components in an architecture grows it´s hard to guarantee uniqueness of pin ids, though. Especially if external systems with their own components are included. So to specify exactly which pin on which component instance is meant in a wire defintion, the pin id can be prefixed with either a component name or a component id. In any case the component needs to be listed in the component reference section.

If pins are of a generic type, e.g. IEnumerable<int>, the pointed brackets can either be encoded as &lt; and &gt; or can be replaced by matching curly braces.

Needless to say that the types of pins wired together need to match.

Last edited May 12, 2010 at 12:12 PM by ralfw, version 10


No comments yet.