ControlCoreServer:Data Model
A data model is collection of object classes (software entities) which are defined to model a particular system. In the context of an embedded system you have a bunch of devices that typically communicate via some shared medium, such as a CAN bus. These devices are complicated entities in their own right, but a collection of such modules, and the interactions between them form a complicated network of information. The volume of information flowing inside and around these device can be overwhelming. A typical embedded system with say, a couple modules, probably contains more information and interactions than a human being can track at the same time. As a result, there is a need for abstraction. Only through abstraction can humans understand such complexity in sync with the system. A way to abstract such details of a system is to create a data model. Data models are themselves, rather complex. Under the covers they tend to contain, in some way, all the details of the system. A well designed data model abstracts this information in such a way that it is usable. Having said that a data model typically contains most, if not all, of the information of the system under the covers and that large systems have TONS of information in them, it should make sense that for such a data model to scale to large systems, it must provide good abstractions.
The key abstractions of the data model behind ControlCoreServer are centered around Signals and SignalProviders. There are conceptually two parts to ControlCoreServer, the hosting of the SignalProviders and Signals, and the framework that makes them available through a multitude of interfaces.
The SignalProvider's main purpose is to abstract away all the details of where/how a signal came to be available. An example or two might illustrate this idea more throughly. Think of a CAN message, sent by an engine controller, to make other modules in its system aware of its current engine speed (RPM). It will typically be transmitted on a bus alongside any number of other messages, having only an ID field to delineate it from the rest. In this message there will usually be between 1 and 8 bytes of content. Somewhere in this content is the information about the speed of the engine. The size of the field containing the message, as well as any scaling or other information necessary to interpret the content is probably contained in some specification that you don't have handy. How do you figure out the speed of the engine when you are presented with the following (flowing by superfast):
0 2007 019 10 37 44.654.96760 0 000001A0 8 00 03 00 01 00 00 00 00
0 2007 019 10 37 44.659.96760 0 000001A0 8 01 00 00 0A 00 0A 00 00
0 2007 019 10 37 44.664.96760 0 000001A0 8 02 00 00 00 00 00 00 00
0 2007 019 10 37 44.664.96760 0 00000220 8 00 00 02 26 00 00 00 00
0 2007 019 10 37 44.669.96760 0 000001A0 8 03 00 00 00 00 00 00 00
0 2007 019 10 37 44.674.96760 0 000001A0 8 04 09 C4 09 C4 00 00 00
0 2007 019 10 37 44.679.96760 0 000001A0 8 05 00 00 00 03 00 00 00
0 2007 019 10 37 44.684.96760 0 00000170 8 00 02 26 04 00 00 01 01
What if you had 100 other things to pick out? Could you keep track? Probably not. Alright, now I hate to tell you this, but, that was a simple example. That information is out in the open, on a shared bus. what if you wanted to know the value of calibration and display variables defined within one of the devices on the bus. This typically involves a stateful calibration protocol, such as the CAN Calibration Protocol (CCP). These protocols involve things such as security mechanisms, stateful data reads/writes, and all other sorts of complicated things. There is no hope that you could keep track of the interactions needed to carry out a session with a module at the pace it is expecting. How do you SEE this information while looking at the system?
This is what SignalProviders do. A SignalProvider would read the CAN message containing RPM and translate that from something like '0 2007 019 10 37 44.684.96760 0 00000170 8 00 02 26 04 00 00 01 01 ' into, say, 500 RPM. A SignalProvider would connect to one of your embedded modules and tell you that there was a signal inside it that would let you modify the gain on your PID controller. You needn't be concerned that it had to parse some DLL, connect to the module, authenticate, and do a data read on table 1, parameter 34 to get that information. It just provides a signal with that information for you.
Back to ControlCoreServer
