In the previous chapter, we presented the Lubrication domain, which is part of an Automatic Lubrication System (ALS). The Lubrication domain delegates to a Signal I/O (SIO) domain controlling and obtaining the necessary data about the lubricated machinery. In this chapter, we describe the SIO domain and show how sensing and control over the external world is accomplished.
From the point of view of the whole ALS, we are producing side effects in the outside world. Indeed, for many systems, it is just these side effects that give the system its utility and purpose. Engineers have devised many ways for happenings outside a computer system to be sensed and controlled by a computer system. Despite the large variety of techniques, there are patterns, rules, and policies that apply to handling sensors and actuators. Sensing and controlling signals form the subject matter we model for this domain.
Because SIO must directly address aspects of the physical world, it may appear that this domain would need to specify platform-specific details. Our model contains abstractions of the real-world electronics that the system hardware presents to us, yet still contains no artifacts of the software platform on which the system executes. For example, we acknowledge that transducers in the outside world produce electrical signals that are converted into digital quantities and that technology forms the basis for interfacing physical quantities to the system. Our SIO model contains abstractions of that real-world fact. But the model artifacts of those abstractions do not include any reference to the specifics of the computing platform on which the system ultimately runs. Those specifics are, of course, supplied by the translation.
The role of the SIO domain in the ALS is to supply services to the Lubrication domain that it needs to accomplish proper lubrication of the machinery. The abstractions that capture the requirements of lubricating machinery are quite different from those of sensing and controlling the external environment. We say there is a separation of concerns between the two domains, as shown in Figure 7-1. The Lubrication domain is concerned with sequencing computation to cause machinery to be lubricated, without worrying about how to acquire the data it needs to perform those computations. The SIO domain is concerned with conditioning and transporting control and data across the system boundary, without caring what the data and control mean. As we show in the next chapter, pycca provides mechanisms for integrating the two worlds.
Figure 7-1. Separation of concerns
We sometimes characterize service domains such as SIO as being at a lower level. We do not use that term in the traditional sense, where higher/lower indicates a relative degree of detail. By lower level, we mean that the subject matter of a domain is less concerned with the business purpose of the application and instead focused on other enabling aspects of the total solution. In fact, a modeled domain cannot be more or less detailed. Every modeled domain is constructed with the same model elements: classes, states, actions, and so forth. To execute, all the elements must specify the same degree of detail. The level of detail is constant, and it is only the subject matter that varies across domains.
Separation of concerns is a tool we use to divide, conquer, and solve the larger problem at hand. By attending to only certain aspects of the larger problem, we find it easier to construct solutions. The separation has the added advantage of allowing us to construct the two domains simultaneously and of potentially reusing the SIO domain in another application that needs control over the outside world.
Of course, creating a separation means that it must at some time be filled. Again, we must emphasize that ignoring an aspect of a problem does not make it mysteriously disappear. We simply note that experience shows that “thinking inside the box” and then “connecting the boxes” together yields a more comprehensible and flexible solution. In the next chapter, we show how the Lubrication and SIO domains are connected back together via a process known as bridging.
Domain Overview
We do not describe all the aspects of the SIO domain in this chapter. The complete domain description and its translation is available as part of the online materials for the book. Our focus here is on translation, so we have picked a few areas of the domain that need to use features of pycca that you have not seen already.
The primary abstraction presented by the SIO domain is the I/O Point. An I/O Point is an idealized view of the way data values are passed between the system and the external world. Clients of SIO read a point to obtain a value of a sensor, and write to a point to assert control over the outside world. I/O Points are given simple small integer identifiers, such as 2 or 27, and clients use these identifiers to read or update the point value.
Clients of SIO always deal with engineering units. Engineering units are the common units with which we are familiar, such as meters, seconds, or kilopascals. Agreeing upon which engineering units are used by a project is vitally important, and there are some notorious examples of what happens if there is a discrepancy (the Mars Climate Orbiter is a relatively recent example). The electrical hardware that interfaces to the system always deals with its own set of units, which we call device units. Device units are specially encoded on a device-by-device basis for the benefit of the electronics hardware. For example, an analog-to-digital converter (ADC) reports the fraction of the measured voltage relative to a reference voltage. How the measured voltage is interpreted in terms of a physical quantity is an element of the electronics design that must specify the calibration or scaling from the ADC voltage to a meaningful physical quantity. One essential function of providing an idealized view of I/O values is to translate between engineering units and device units (and vice versa).
SIO does compute the correct values in device units for controlling the hardware interface but delegates that actual update and access of hardware to an external entity. This may seem strange, but delegating the access to the physical hardware controls to a device access entity means that the many and varied ways in which hardware controls are accessed does not become entangled into SIO. For example, some hardware controls are mapped into memory. Some are mapped onto external busses. Depending on the operating environment, special permissions may be required. Although SIO computes the right bits in the correct device units, it does depend on something else to transport those bits to the hardware control registers.
Often for the type of systems that we target here, device access code is supplied as part of a software library available from the manufacturer of the microcontroller chip. These libraries are often called hardware access layers and usually provide functions for common peripheral device operations. For example, a system on a chip (SOC) microcontroller may have supplied functions to run the on-board ADC. Such libraries are useful because they usually encode details of the device operations that can be difficult to determine solely from the chip design manual. It is necessary to supply a bridge from SIO to the device access code. Such a bridge follows the same pattern of bridging we describe in the next chapter. For hardware access, we are bridging to manually written code (written either by the chip manufacturer or by the project), and it is part of the solid ground we use to build up the rest of the system.
Converting Electrical Signals
Most systems that interact with the outside world need to measure physical quantities. Even conventional desktop computers usually measure the temperature of the processor to control the fan speed and ensure that the CPU doesn’t overheat.
A common way to measure physical quantities is to use a transducer. A transducer is a device that produces an electrical signal, typically a voltage, that can be related to a physical property, usually by linear scaling. An ADC is typically used to interface transducer signals.
Digitizing signals is an ubiquitous operation and a distinct specialty in the computing world. We take a much simpler view of things here. Figure 7-2 shows in block form the hardware arrangement that we assume.
Figure 7-2. Block diagram of ADC hardware
The ADC typically has a multiplexer that acts as a switch. This allows many signals to be wired physically to the ADC, and one is selected via the multiplexer. It is also common that several signals need to be sampled at the same time. This might happen if the signals represent different instances of the same quantity sampled at the same rate or have some other correlation in time such as two quantities used to compute a third value. The ADC cannot convert multiple signals simultaneously, but it can convert a signal and switch the multiplexer to convert another signal fast enough that it can be effectively time shared between multiple signals. Most ADC peripherals support converting a series of inputs as a distinct mode of operation requiring no additional CPU intervention.
Modeling Signal Conversion
Figure 7-3 shows the fragment of the class diagram that deals with signal conversion.
Figure 7-3. Classes dealing with signal conversion
The essential rules are as follows:
Input points that must be sampled at the same time are grouped together (R4). A group of one is used for those points with no correlation to other points.
Grouped input points are all wired to the same Signal Converter (R5).
At any point in time, at most one group of signals is being converted and there are times when the Signal Converter is idle (R6).
Each Conversion Group has its own sampling period. The period is the amount of time to elapse between samples being taken. This implies that at some point in time, two conversion groups may need access to the same Signal Converter, or the Signal Converter may be in use at the same time a conversion group decides to sample its inputs.
From the modeling point of view, we must be careful about how the R6 association is managed. It is necessary to serialize the processing associated with creating and deleting instances of the R6 association. This is accomplished with an assigner. An assigner is a state model attached to an association that manages competition among the instances of the association. Rather than state activities creating or deleting instances of the association synchronously, they signal events to the assigner declaring their intent. The state activities of the assigner function as a single point of control to coordinate the life cycles of the association instances to ensure proper access to the Signal Converter. Because our focus here is translation, we do not discuss the general background of competitive associations and the protocols used to ensure the proper sequencing of operations. See Executable UML: A Foundation for Model-Driven Architecture for more about how to recognize and model competitive associations and construct assigner state models.
Figure 7-4 is a sequence diagram for one possible event sequence in which a group of points needs to be sampled. This is the sequence that would happen the first time a conversion group is requested to be sampled, assuming the corresponding Signal Converter is not being used.
Figure 7-4. Event sequence assigning a Signal Converter
The state models for the R6 assigner along with those for Conversion Group and Signal Converter cooperate to ensure that Signal Converter access is properly serialized among the competing instances of Conversion Group. Clients can request the Conversion Group to begin sampling, which, in turn, signals the R6 assigner it is ready. Because this is the first time through, the assigner detects that the Signal Converter is available and signals Converter ready to itself. That transition causes the Signal Converter to be signaled with the Converter assigned event, which causes the Signal Converter to request the conversion from the hardware. Meanwhile, the R6 assigner signals to itself that a converter is assigned and transitions to a state in which no other conversions are allowed until the ongoing one is completed.
When the hardware finishes the conversion, it signals Conversion done to the Signal Converter, which reads the converted values and processes them. The Conversion Group is signaled to tell it that the sampling has been accomplished, and the assigner is signaled with the Converter ready event to inform it that another Conversion Group may be assigned.
Figure 7-5 shows the state model for the R6 assigner.
Figure 7-5. R6 assigner state model
Note in particular that for this state model, if another Conversion Group signals Group ready while a converter is still converting the signals of a previously assigned group, the state machine remains in the WAITING FOR CONVERTER state until the Signal Converter signals Converter ready, indicating that it is ready to perform another conversion. This ensures that two conversion groups don’t try to use the signal converter at the same time. Conversely, if the conversion finishes before another group needs to be sampled, the Converter ready event is ignored in the WAITING FOR GROUP state as we remain in that state until a Conversion Group requests the signal converter. The state model defines a sequencing protocol between the Conversion Group and Signal Converter classes to ensure that access to the Signal Converter is serialized properly.
The following transition matrix is for the R6 assigner.
Group ready | Converter ready | Converter assigned | |
WAITING FOR GROUP | WAITING FOR CONVERTER | IG | CH |
WAITING FOR CONVERTER | IG | Assigning Converter | CH |
Assigning Converter | CH | CH | WAITING FOR GROUP |
Note the ignored events. Ignoring the Converter ready event when waiting for a Converter Group and ignoring the Group ready event when waiting for a Signal Converter are an essential aspect of the way the R6 assigner serializes the access to the Signal Converter by the competing Converter Groups.
Figure 7-6 shows how a Conversion Group notifies the assigner that it needs the Signal Converter.
Figure 7-6. Conversion Group state model
The Conversion Group signals the assigner that it needs to perform a conversion and then waits to be told that the conversion has been done. The Sample and Stop events are used to start and stop the periodic conversion of the group of points.
Finally, Figure 7-7 shows how the Signal Converter operates.
Figure 7-7. Signal Converter state model
After being assigned to a Conversion Group by the R6 assigner, the Signal Converter requests the device to perform the conversion and then waits for it to be done. Then it is necessary to retrieve the converted values and update the values of the input points. Note that the CONVERSION COMPLETE state activity deletes the instance of the R6 association because it knows when the conversion process is complete and because there is a one-to-one correspondence between Signal Converter and R6 association instances.
Because input points are physically wired by the electronics design to a particular Signal Converter (as stated by R5), there must be an instance of the R6 assigner for each Signal Converter class instance. It is not possible to allow an arbitrary Signal Converter to sample an arbitrary Conversion Group. Such an arrangement is called a multi-assigner because there are multiple instances of the assigner state machine. For the simpler case in which an arbitrary resource can be allocated to an arbitrary user of that resource, there needs to be only a single instance of the assigner. For a multi-assigner, one class always serves to partition the instances of the assigners among the resource users. Formally, a multi-assigner can be identified by the same identifying attributes as for the partitioning class. In this case, it is the Signal Converter class that partitions the assigner instances, and the number of instances of the R6 assigner state machine equals the number of instances of the Signal Converter class.
Implementing the Assigner
We use a pycca class to implement the R6 assigner. Although the assigner is not a class from the model point of view, a pycca class has all the implementation characteristics we need—namely, attributes, state models, and the ability to have multiple instances. This also demonstrates that a pycca class is an implementation construct and not the same as a model class. We use a pycca class to implement a model class, but we also use it to implement an assigner.
The pycca implementation follows the usual pattern we have already seen; however, the callouts point to distinct usage that is specific to implementing assigners:
class R6_Assignerreference idclass -> Signal_Converter # ❶machinedefault transition CHinitial state WAITING_FOR_GROUPtransition WAITING_FOR_GROUP - Group_ready -> WAITING_FOR_CONVERTERtransition WAITING_FOR_GROUP - Converter_ready -> IGtransition WAITING_FOR_CONVERTER - Group_ready -> IGtransition WAITING_FOR_CONVERTER - Converter_ready -> Assigning_Convertertransition Assigning_Converter - Group_ready -> IGtransition Assigning_Converter - Converter_ready -> IGtransition Assigning_Converter - Converter_assigned -> WAITING_FOR_GROUPstate WAITING_FOR_GROUP () {ClassRefVar(Signal_Converter, sc) = self->idclass ;ClassRefConstSetVar(Conversion_Group, cgset) ;PYCCA_forAllRelated(cgset, sc, R5) { // ❷ClassRefVar(Conversion_Group, cg) = *cgset ;if (cg->Waiting_for_converter) {PYCCA_generateToSelf(Group_ready) ;return ;}}}state WAITING_FOR_CONVERTER () {ClassRefVar(Signal_Converter, sc) = self->idclass ; // ❸if (sc->Converter_available) {PYCCA_generateToSelf(Converter_ready) ;}}state Assigning_Converter () {ClassRefVar(Signal_Converter, sc) = self->idclass ;assert(sc->Converter_available) ;ClassRefConstSetVar(Conversion_Group, cgset) ;PYCCA_forAllRelated(cgset, sc, R5) {ClassRefVar(Conversion_Group, cg) = *cgset ;if (cg->Waiting_for_converter) { // ❹sc->R6 = cg ;sc->Converter_available = false ;cg->Waiting_for_converter = false ;PYCCA_generateToSelf(Converter_assigned) ;PYCCA_generate(Converter_assigned, Signal_Converter, sc, self) ;return ;}}}endend
❶ Because this is a multi-assigner partitioned by Signal Converter, we need a reference to the Signal Converter instance on whose behalf this assigner instance is operating. The reference to an identifying class has the net effect of giving the assigner the same identifying attributes as Signal Converter.
❷ Iterate across the instances of Conversion Group related by R5 looking for one waiting to be sampled. Here, cgset is an iterator that is assigned successive values of pointer to the instances related across R5.
❸ There is no need to search for the Signal Converter that this instance is assigning. There is a one-to-one correlation between R6 assigner instances and Signal Converter instances.
❹ Again, we find a group that is waiting to be converted. We select the first one we find and assign the Signal Converter to it.
There is no specific policy implemented for deciding between multiple, waiting Conversion Groups. If the requirements, and hence models, specified a particular policy for resolving the contention, it would be implemented here. One possible policy might be “first come, first served,” but that is not what this code does. This code assigns Conversion Groups based solely on the order in which they were related to the Signal Converter. This would correspond to a requirement of assigning an arbitrary waiting Conversion Group and, because the requirements allow for any Conversion Group to be assigned, we have chosen the most convenient and efficient implementation. In general, the requirements for selecting how a resource might be allocated in the presence of contention can be complex. Here we have taken the simple approach for the benefit of the example.
Tracing Execution
As we discussed in Chapter 5, translated models executing on the ST/MX domain can generate an execution trace. The following is a trace of the event transitions involving the R6 assigner. In this scenario, two instances of Conversion Group are both connected to the same Signal Converter. The event sequence has been constructed to ensure that there is competition for access to the Signal Converter. The trace shows how the R6 assigner correctly serializes the Converter Group requests.
1 (nil) - Sample -> Conversion_Group.cg1: FINISHED -> WAITING_FOR_CONVERSION ❶2 Conversion_Group.cg1 - Group_ready -> R6_Assigner.r6asgn1: WAITING_FOR_GROUP ->WAITING_FOR_CONVERTER3 R6_Assigner.r6asgn1 - Converter_ready -> R6_Assigner.r6asgn1: WAITING_FOR_CONVERTER ->Assigning_Converter4 R6_Assigner.r6asgn1 - Converter_assigned -> R6_Assigner.r6asgn1: Assigning_Converter ->WAITING_FOR_GROUP5 R6_Assigner.r6asgn1 - Converter_assigned -> Signal_Converter.cvt1: CONVERSION_COMPLETE ->CONVERTING6 (nil) - Sample -> Conversion_Group.cg2: FINISHED -> WAITING_FOR_CONVERSION ❷7 Conversion_Group.cg2 - GroupReady -> R6_Assigner.r6asgn1: WAITING_FOR_GROUP ->WAITING_FOR_CONVERTER8 (nil) - Conversion_done -> Signal_Converter.cvt1: CONVERTING -> CONVERSION_COMPLETE ❸9 Signal_Converter.cvt1 - Conversion_done -> Conversion_Group.cg1: WAITING_FOR_CONVERSION ->CONVERSION_COMPLETED10 Signal_Converter.cvt1 - Converter_ready -> R6_Assigner.r6asgn1: WAITING_FOR_CONVERTER ->Assigning_Converter11 R6_Assigner.r6asgn1 - Converter_assigned -> R6_Assigner.r6asgn1: Assigning_Converter ->WAITING_FOR_GROUP12 R6_Assigner.r6asgn1 - Converter_assigned -> Signal_Converter.cvt1: CONVERSION_COMPLETE ->CONVERTING13 (nil) - Conversion_done -> Signal_Converter.cvt1: CONVERTING -> CONVERSION_COMPLETE ❹14 Signal_Converter.cvt1 - Conversion_done -> Conversion_Group.cg2: WAITING_FOR_CONVERSION ->CONVERSION_COMPLETED15 Signal_Converter.cvt1 - Converter_ready -> R6_Assigner.r6asgn1: WAITING_FOR_GROUP -> IG
❶ The first five lines of the trace show the sequence of event dispatches to start the sample conversion for Converter Group cg1. These events correspond to those shown in the top part of Figure 7-4.
❷ Converter Group cg2 is requested to sample before the hardware has completed the conversion for Converter Group cg1. The Group ready event sent to the R6 assigner (line 7) causes it to transition to the WAITING FOR CONVERTER state, and there it examines the Signal Converter to determine that it is not available at this time. This causes the assigner to remain in the WAITING FOR CONVERTER state.
❸ The hardware has completed its work, and this initiates a sequence of event dispatches that eventually end up with the Signal Converter signaling Converter ready to the R6 assigner. Because a Conversion Group is ready to go, it is assigned the Signal Converter, and the next sample is initiated.
❹ The second conversion is done. When the Signal Converter signals Converter ready to the assigner, the event is ignored (line 15), as there are no ready Conversion Groups at this time.
Limitations
Sampling values in the manner that we have shown here is limited to relatively low frequencies, on the order of a few hundred Hertz. The timing for sampling points is controlled by software, and that will necessarily create jitter in the timing precision. The fastest that can be sampled is 1,000 Hz, because we are using delayed signals and the delay time resolution is 1 millisecond.
In the larger data acquisition world, this is a low data rate, so our simple example should not be applied indiscriminately. It is, of course, possible to do better, but it means moving more of the work into hardware. Our view of that underlying hardware would be different from what we showed earlier. Each hardware arrangement will require some software control, and that can be modeled and implemented by using the techniques shown here. What differs is the underlying hardware reality that the software model controls. What does not change is the service interface that the SIO domain presents.
Value Thresholds
Frequently, we are not so concerned about the value of a point but rather how that value compares to a threshold. In the Lubrication domain, we saw the domain needed to have the lubrication pressure monitored to ensure that it was in the correct pressure range to be effective. To support that delegated capability, the SIO domain implements value threshold concepts and provides a way to compare values to defined limits.
Figure 7-8 shows an example of a value threshold. As point values are sampled over time, the value may rise above a specified threshold limit. When that happens, the value is deemed out of range. It remains out of range until it falls below the threshold limit at which time it is deemed to be in range.
Figure 7-8. Threshold limit on a value
This diagram shows a rising-edge detection of the out-of-range condition. If you invert the value comparisons, you have the complementary form of falling-edge detection, which detects a point considered out of range when the point value falls below the threshold limit. By defining two threshold limits, one for a rising-edge comparison and one for a falling-edge comparison, then a value can be monitored to determine whether it is between upper and lower limits.
When deciding whether a value exceeds a threshold, we want to prevent oscillations near the threshold limit from repeatedly triggering the out-of-range condition followed immediately by an in-range condition. We use a simple counting filter to supply hysteresis to the detection. If we delay the determination that a value is out of range or in range until we have seen a certain number of consecutive excursions above or below the threshold, we can prevent minor fluctuations of the value causing a spurious detection of being out of range. If we want to see each time a value exceeds its threshold, we can set the limit number to 1. There are, of course, many other possible ways to add hysteresis to the threshold determination, but simple counting schemes are both effective and, when translated, computationally efficient.
Figure 7-9 is a class diagram that captures these ideas.
Figure 7-9. Class diagram for Range Limitation
Each input point may have multiple Point Thresholds specified for it. In our example, we use three Point Thresholds to monitor an injector’s lubrication pressure to know if the lubricant pressure is sufficient, if there is excessive dissipation pressure, or if the maximum allowed pressure is exceeded. A Range Limitation is an instance of applying a Point Threshold to the value of a Continuous Input Point. We may define one Point Threshold and apply it to several input points, but we will need a separate instance of Range Limitation for each of those applications. The computations necessary to detect the threshold excursions are specified in the state model for the Range Limitation class.
Figure 7-10. Range Limitation state model
We do not show the entire pycca implementation of the state model here because it follows the same pattern you have already seen. We do, however, show the state definition of the Checking Out Of Range state:
state CHECKING_OUT_OF_RANGE(sio_Point_Value pointValue) {ClassRefVar(Point_Threshold, pt) = self->R7_PT ;bool outRange = pt->Direction == Rising ?rcvd_evt->pointValue > pt->Limit :rcvd_evt->pointValue <= pt->Limit ; // ❶if (outRange) {if (++self->Over_count >= pt->Over_limit) {PYCCA_generateToSelf(Out_of_range) ;}} else {self->Over_count = 0 ;}}
❶ Pycca defines a pointer named rcvd_evt to access event parameters. The variable name and parameter access technique is an unfortunate choice that will be improved in a future release.
Initial Instance Population
In this section, we present part of an initial instance population for the Signal I/O domain. This population corresponds to the needs of the Lubrication domain as it was populated in Chapter 6. We do not show the entire set of values in the population, but only those parts that pertain to converting signals and detecting value threshold limits. The complete population is available in the online materials.
Supporting the needs of the Lubrication domain population requires eleven I/O Points: three for Machinery lockouts, two for Reservoir levels, three for Injector pressure, and three for Injector solenoids. We focus here on the three I/O Points associated with the Injector pressure because they must be both sampled and compared against threshold limits.
Injector pressure is represented by a Continuous Input Point whose value represents the lubricant pressure at each injector. Each injector has a transducer for pressure that is sampled and converted to the value of the Continuous Input Point.
ID | Value | Group |
inj1_pres | 0 | inj1_cg |
inj2_pres | 0 | inj2_cg |
inj3_pres | 0 | inj3_cg |
The I/O Points for the injector pressure are formed into three Conversion Groups, each group containing only a single point.
ID | Waiting for converter | Period | Converter |
inj1_cg | false | 500 | cvt1 |
inj2_cg | false | 500 | cvt1 |
inj3_cg | false | 500 | cvt1 |
We assume that only a single Signal Converter is attached to the system and that all the injector pressure transducers are wired to it.
ID | Converter available |
cvt1 | true |
The Lubrication domain assumes that Signal I/O will perform threshold comparisons on the injector pressure values. Three thresholds must be determined: above the dissipation pressure, above the injection pressure, and above the maximum pressure. From the Lubrication domain population, we know that there are two Injector models. Our pressure threshold values are selected based on the different injector designs.
ID | Limit | Direction | Over limit | Under limit |
ix77b_above_disp | 26 | Rising | 2 | 2 |
ix77b_above_inj | 15 | Rising | 2 | 2 |
ix77b_max_pres | 26 | Rising | 1 | 2 |
ihn4_above_disp | 32 | Rising | 2 | 2 |
ihn4_above_ing | 19 | Rising | 2 | 2 |
ihn4_max_pres | 35 | Rising | 1 | 2 |
With three injectors and three thresholds for each injector design type, we have nine instances of Range Limitation to detect all the threshold excursions that the Lubrication domain requires.
Point | Threshold | Over count | Under count |
inj1_pres | ix77b_above_disp | 0 | 0 |
inj1_pres | ix77b_above_inj | 0 | 0 |
inj1_pres | ix77b_max_pres | 0 | 0 |
inj2_pres | ihn4_above_disp | 0 | 0 |
inj2_pres | ihn4_above_inj | 0 | 0 |
inj2_pres | ihn4_max_pres | 0 | 0 |
inj3_pres | ix77b_above_disp | 0 | 0 |
inj3_pres | ix77b_above_inj | 0 | 0 |
inj3_pres | ix77b_max_pres | 0 | 0 |
Summary
In this chapter, we have shown a model and translation for the SIO domain. This domain handles interactions with the external world by sensing values and controlling actuators. We focused on two particular capabilities that are delegated to the SIO domain by the Lubrication domain:
Sampling values of sensors
Comparing sampled values against thresholds
For value sampling, our model included an assigner state model to manage the competition that is inherent in the physical arrangement of our electronics design.
For value thresholds, we saw how a state model attached to an association class provides the means to track multiple threshold limits applied to the same input point.
In both cases, we saw rules and policies applied to collecting and evaluating data from the external world. From the point of view of the SIO domain, the values and meaning of the data were no of concern. From the point of view of the Lubrication domain, it needs current, up-to-date data values, and the rules of how the electronics design affects acquiring data is of no concern. This separation of concerns allows us to focus on the development of a consistent set of abstractions for both domains and to potentially reuse the SIO domain in another application that has similar needs to interact with the external world.