The STEAM project is addressed to develop a set of open architectures, protocols, and software for automating (monitoring and controlling) scale-model systems, as diy robots or scale-model trains could be, but not limited them.
The STEAM project is, by nature, hardware-agnostic, what means that it is open to support any hardware devices and network protocols as long as the hardware devices firmare was STEAM protocols compliant and the network protocols were able to handle the information that a set of STEAM compliant components exchange.
The STEAM project is, by nature, hardware-agnostic, what means that it is open to support any hardware devices and network protocols as long as the hardware devices firmare was STEAM protocols compliant and the network protocols were able to handle the information that a set of STEAM compliant components exchange.
Regarding the scale-model trains, in the late years an improvement in technology has been done, moving from systems controlled by voltage regulation and electric and mechanical switches to a scenario in which the control can be performed partly or fully in a digital way (mainly by using Power Line Communication solutions). However a set of unsolved problems still remain, as the "exclusivity" of control systems that avoids different technologies working together at layout level, the lack of bidirectionallity, PLC (power line communication) associated problems, etc.
In that way, the STEAM project is addressed to offer solutions to, at least, the previously defined problems from a botton-up perspective: it will focus on automatic scale-model trains for its hardware and software primary works while avoiding restricting the interfaces and protocols to that specific sector, so an easy extrapolation of the results to, for instance, robot controlling, could be feasible.
The final objective is having not just the architecture and protocol definitions, but demonstration hardware and software functional components that allowed evaluating the project results and, therefore, speed-up an easy adoption of them by the community.
The final objective is having not just the architecture and protocol definitions, but demonstration hardware and software functional components that allowed evaluating the project results and, therefore, speed-up an easy adoption of them by the community.
Licensing
The project is launched as an open-source initiative under MIT licensing. That means that the architecture and data exchange protocols are open, built and mantained by the community, and hopefully that software developments and hardware designs were launched as open source too.
However it is important to state that the MIT licensing is one of the most permissives licensing models, giving great flexibility to the licensing and commercialization of the developments taking as base the STEAM project results. That means that, for instance, commercial products could be derived from this project with no copyright problems. Following this approach both open source developments and commercial products can use STEAM as base, maximizing its utility and -hopefully- popularity.
Why "STEAM"?
STEAM is the name that was given to that project in its earlier stages. Apart of (partly) standing from "open scale-model SysTEm AutoMation", it's a cool name for a project whose initial focus was the automation of scale-model trains.
Does that mean that it is the definitive name? It is just a name for start working with the objective of being reviewed (and probably changed) if the project matures in term of development and adoption.
The STEAM logo is a vapor icon created by Laura Burk and then shared under a Creative Commons license in The Noun Project website. As the project name, the logo suitability is potential discussion object, but until that moment came (if it does) it is nice to have it as visual reference of the project.