Getting Started
In brief, a scale model system is a set of input/output devices (sensors and actuators) that can be combined in complex machines to perform some tasks on a phisical environment called layout. These machines, or set of devices, are controlled by smart devices that form, together with the machine, a layout item or Litem. Litems are connected to a highest level Manager, the entity in charge of granting the end-user full control on the scale model system.
At this point let's put some examples:
- A diy robot composed by two motors and a PIR sensor, and controlled by an Arduino with Bluetooth capabilities would be a Litem with one machine composed by one input device (the PIR sensor) and two output devices (the motors) with a controller (the Bluetooth Arduino). That robot, from now on a Litem, would perform task on an environment called layout and would be managed by the end user through the Manager. Note that, by nature, a robot is autonomously able to perform some tasks by itself, however a real-time control from the end-user is desirable (for instance for changing robot programming parameters).
- A scale-model train locomotive with one motor and two sets of lights (front and rear) controlled by a DCC enabled decoder. In this case the train (machine) is composed by three output devices (one motor, one front-lights relay and one rear-lights relay) and a controller (the DCC decoder). The train would perform tasks on a layout and the user would control it by means of the Manager. Opposite to the robot, it is expected that the scale-model locomotive made nothing by itself, it is therefore fully dependant from the control provided by the end user.
As can be seen in the previous image, a dotted line joins the Litem and the Manager: STEAM proposes a hardware-agnostic approach, that means that different Litem technologies (both hardware and connectivity) can work together on the same layout and can be controlled by a single Manager. To do that an intermediary, called Concentrator, is necessary between the manager and the smart devices, so the Concentrator could abstract the manager of the smart device technological detail and, therefore, giving the manager an unified vision of all the Litems, whatever technology were they based on. This is described on the next scheme:
Again lets put some examples:
- For the case of the robot, being controlled by a Bluetooth Arduino, the concentrator would be a software layer running on a computer with a Bluetooth card (something easy to find) in which the Manager would run too.
- For the case of the train, in which finding a computer with a DCC card is not so common, the concentrator could be a device (let's say a Raspberry Pi) with at least one DCC daughter board (used for accessing to the "train" litem) and an ethernet port (used for connecting concentrator and Manager).
Finally, let's increase the definition scope of the Litems. In the first paragraph it has been stated that the devices that allow a Litem interact with the layout do it by allowing sampling data from the layout (input devices) or by performing actions on it (output devices). Let's add a third group of devices that would act as a data gateway to another devices able to both performing some actions based on these data (output data) or, opposite, sampling these data and then transfering it to the Manager via the Litem controller (input data).
In order to put an example of this third group, let's imagine that our scale-model train has a I2C sound module that is able to reproduce some pre-recorded sounds based on a sound sample id received by its I2C interface. So, for instance, when receiving a "1" a horn sound is reporduced, and when receiving a "9" a brake sound is reproduced. In that case, our machine will have four devices: one motor (output), two relays (lights) and one I2C (sound module).
Let's go farther adding a new I2C module, this time a NFC receiver able to read some layout tags and, therefore, generating information useful for locating the locomotive in the layout. By reading this device, the Litem will generate an event every time that data was received from it, leveraging the Manager of performing a continous poll on it. Though it uses the same interface that the sound player (I2C), it is a different device with different functionalities. So now our Litem is composed by five devices: one motor, two relays and two I2C devices.
As it has been seen in the previous point, based on the nature of its devices, a Litem has different functionalities. Or said in another way: a Litem contains devices with different functionalities. These functionalities can be managed considered them as:
- Properties, that can be obtained from or set to a device. For instance, in the case of the train motor a property could be the acceleration curve, ie, how much time will spend the motor from changing from a initial to a final speed.
- Actions that a device can perform. For instance, in the case of the train motor it can change its speed to a new value, in a range from 0 to 100, or a relay can be opened or closed and, therefore, the train lights can be switched on or off.
- Events that trigger under certain circumstances. For instace, the NFC I2C device would trigger an event every time it reads a tag.
As previously exposed, the main task of a Concentrator is granting the Manager access to the distinct Litems, whatever the underlying technology (hardware/network) or features it had. To do that it must identify the Litems in a way that was independent of its technology.
Again, let's exemplify it. Let's imagine that we add new items to our train layout, this time a couple of rail switches. These switches are modelled as Litems with a "relay" device on it that allow moving the switch one side or another depending on the on/off state of the "relay" device that represents it. In that way, a left switch would be switched (therefore the trail will "turn" left) when its relay was ON (by calling the Litem action "On").
Instead of using DCC communication, these new Litems are based on 802.15.4 communication, so a new 802.15.4 concentrator is added to the layout together with the existing DCC concentrator. Network device addresses in DCC and 802.15.4 networks has nothing in common, so in order to allow the Manager operate the Litems, it is necessary that it saw the Litems in two networks as a unified set. Therefore each coordinator must assign a logic address to each Litem, whatever the underlying network it was.
So, the DCC concentrator will assign the address "A" to the train Litem and the 802.15.4 concentrator will assign the address "A" to the switch Litem. Though the Litem addresses are the same the concentrators are different, so from the point of view of the Manager the train Litem will be the "Alpha.A" Litem (providing that the DCC concentrator was addressed as "Alpha" by the Manager) and the switch litem will be the "Beta.A" Litem (providing tha the 802.15.4 concentrator was addressed as "Beta" by the manager).
Finally, in some circumstances the concentrators should provide management functions on the underlying (Litems) network. In the case of of the 802.15.4 concentrator, a PAN (Personal Area Network) coordinator must exist in order to create and mantain the network (equivalent to an access point in a 802.11 "WiFi" networks). In this case, the concentrator might support these tasks, providing the Manager the suitable interface for managing it, or might rely on a third-party device invisible from the point of view of the Manager.
The Manager becomes the end-user access point to the layout. It converts the user requests into specific Litem commands (as setting/reading properties and/or invoking actions) and processes the events comming from the Litems. To do that uses the concentrators as gateways to the Litems, so managing the concentrators (adding/deleting, identifying) is other of its tasks.
Let's see some Manager examples. The simplest Manager could be a smart device (let's say an Arduino) with a single button for controlling a buzzer (a relay Litem) based on Bluetooth. In this case, the concentrator would be a thin layer into the Manager firmware that would act as a bridge between an upper layer (the Manager itself) and the buzzer. Every time the user pressed the button, the Manager would ask the concentrator to send the Litem an "On" action for activating the buzzer. Upon Manager request, the concentrator should search for new Litems and, every time it detected a new one (in this example just one would be detected) a logic address whould be assigned to it, that address used by the Manager to reference the Litem.
One much more complex Manager could be that addressed to a scale-model layout system with tenths of Litems based on different network protocols, one of them being 802.11g (WiFi). In this scenario, the Manager could be a software program running on a computer with ethernet and WiFi ports. The ethernet network would link the Manager with a set of concentrators managing every Litem network (let's talk about DCC and 802.15.4 Litem networks), being these concentrators two Raspberry Pi devices, every of them with the suitable hardware for connecting the concentrator with the ethernet and the DCC/802.15.4 networks. Since the computer where the Manager runs has a 802.11g interface, the third concentrator would be a software layer running on it and performing exactly the same functions than those running on the Raspberry Pi, except for those intrinsically bound to the underlying network management (let's assume that the 802.15.4 concentrator acts as a PAN coordinator). This Manager would have a Human Machine Interface giving the user full vision and control of the layout, with each item (trains, lights, rail switches, signals, ...) properly mapped to a Litem. Every time the user performed an action, the Manager would convert it to a specific Litem request, properly forwarded by the Litem concentrator. Opposite, every time something happened on the phisical layer, the info would reach the Manager via the Concentrator, and would be converted to some form of information addressed to the end user.
These two examples are extreme, and for sure the first one would be easy to implement with a more specific approach that using STEAM. However they serve for the purpose of showing the flexibility that the exposed architecture offers. Though achieving that flexibility implies a higher development complexity effort, it offers key advantadges:
- It allows adapting STEAM to different scenarios, not just (for instance) scale-model train control but any scenario in which criticity or security concerns were not relevant. Some suitable scenarios would be diy robotics, toys, scale-model trains, slot cars and even (though it is not intended for that purpose) home automation.
- It allows putting together different device/network technologies working coherently. This is a disruptive feature regarding the most of the STEAM applicable scenarios, where just one Litem technology is used, no matter if it is the most suitable.
- Modelling the phisical devices in base to known, simple logical devices allow simplifying the code since an small set of simple, same well known objects will be used the most of the times.