tn 3 Half Table Study: Signal IO MTC Example
mint.sm-meta.system.tn.3 / Leon Starr / Version 0.2.0 in progress / 22-7-9
Chapter eight of [MTC] examines bridging necessary to suppor the auto lubrication example. In this note we will re-examine some of that bridging in the context of our bridge subsystem work.
In our Lubrication client domain we have an Injector class and we need to command the start and stop of injection for each injector via the Signal IO (SIO) service domain. There are a couple of ways that we could do this. In the book, we invoke a Start injecting or Stop EE operation on an SIO EE. This, in turn, is mapped to an EE defined in the SIO domain. Another possibility would be to dispense with the start/stop EE operations on the client side and simply map certain Injector states such that entry into those states would implicitly start or stop injection. There are merits and disadvantages to the second approach, so we will consider it later and stick to the first idea.
Instead of defining an SIO external entity in the client domain, we will use the class proxy approach defined in [EE] and define an INJECTOR EE instead. The start and stop operations will be considered EE egress operations. We must then map them to some element in the SIO domain.
Here are the redefined external entities and their operations on each side of the bridge.
Next we introduce two additional subclasses of Bridgeable Entity (BE) so that we can define our Join Points.
As usual, the modeler is responsible for selecting the Join Points and mapping them. Mapped Parameter Value is similar to Mapped Attribute Value introduced in tn1. Once again, the values are really just type selector operations which, in this case, are defined on the Boolean type.
But we're not done yet since an invocation of either of the client's EE operations must map from the associated Injector instance to some instance of IO Point. We know the value to write to an IO Point, but we need to know which IO Point to write! This means that we need a class to class mapping as shown:
We are going to recast this example similarly. In [MTC] A Start monitoring a signal to an EE in the client is mapped to an event specification in the service and instances of Injector in the client are mapped to instances of Conversion Group in the service.
We add an EE for the SIO Conversion Group class named CGROUP. And then, instead of mapping signals to event specifications as we did in [MTC], we simply map EE operations together on both sides.
The next step is to define the ee operations on the service side.
And that's it.
In this example, we have a single attribute Injector.Pressure in the client domain that maps to the Continuous Input Point.Value attribute in the service domain. The Continuous Input instance reads a raw input value, applies its related Point Scaling instance to yield a refined value.
We want to ensure that when the client reads Inject.Pressure it gets the current value read by the Continous Input Point. And we want to do this seemlessly. The client domain should simply read its own attribute and always get the Continuous Input Point value wiithout making any explicit call to the SIO domain.
Here we need to map a one or more client attributes to the same attribute in the service domain. We did something similar in tn1 with the Animation example. Here are the attribute to attribute join points:
We also need to map the Injector and Continuous Input Point classes and instances. Nothing new here, but here are the tables:
We now need to think about the actions. When a read action is invoked on the Injector.Pressure attribute, anywhere in the Lubrication domain, we need to have it obtain its value from a corresponding Continuous Input Point.Value value.