Now, Kickstarter projects like Ninja Blocks are shipping Internet of Things (IoT) devices based on the BeagleBone (see this article’s lead-in photo), and startup GEEKROO is developing a Mini-ITX carrier board that will turn the Raspberry Pi into the equivalent of a PC. Outside of the low barrier to market entry presented by these low-cost development platforms, maker boards are being implemented in commercial products because their wide I/O expansion capabilities make them applicable for virtually any application, from robotics and industrial control to automotive and home automationsystems. As organizations keep enhancing these board architectures, and more hardware vendors enter the DIY market, the viability of maker platforms for professional product development will continue to increase.
It is the author’s opinion that integration of the controls networking and the IT network is inevitable. It became inevitable the moment the controls industry chose to use Ethernet as the medium with which to communicate data. The controls industry may choose to be dragged kicking and screaming into the modern automation era, or it can gracefully embrace the change. Embracing means the controls industry would be able to leverage the myriad rich, existing technologies that have been proven foolproof in the IT world. To be dragged kicking and screaming into the modern communications era would do a terrible injustice to those who have worked diligently to bring it about. This could quite possibly add an entirely new facet to the fieldbus wars, which I hope have not been forgotten.
With that said, the controls world is going to be moving with an industry that has a definite consumer bias, with product development and release cycles of six months or less. In an industry where the average life expectancy of an automotive production line is eight years, it is impossible to expect the networking in an industrial setting to keep up with modern IT standards. Therefore, we turn our attention to the technologies that have existed the longest, with the most open standards and the very best support. These are the protocols we wish to use and keep, and this article highlights and explains some of these technologies.
This article does not focus on the technical implementations of each piece of technology. Rather, it is assumed the reader will be using packaged solutions such as a function block for a PLC. These packages typically require only that the user specifies the relevant server to connect to, the data to be gathered and an activation bit. The particulars of each protocol and concept are, ideally, transparent to the user, and therefore it is not pressing that the user understands what is contained in each packet passed between the server and the client. As each protocol described in this article is openly documented and supported, a simple search on the Internet for the technical details will likely yield the relevant automation details.
The possibilities for embedded product designs are exploding. Leveraging a myriad of connectivity interfaces and integrating advanced graphical user interfaces and multimedia formats requires the availability of supporting software stacks from the underlying operating system. And, more than ever before, embedded software teams are turning to open source software and embedded Linux as the platform on which to base these systems in the “Internet of Things.” But while open source has proved itself incredibly technology enabling, it can also make the workflow excessively unwieldy. The good news is that solutions and best practices exist to help development teams improve their embedded product workflow when open source is an increasingly large part of the mix.
Ensuring that the development team is aware of embedded computer – and in compliance with – the obligations associated with each of these open source licenses takes time and effort. Tools that can help to identify and track the underlying licenses that apply and enable license obligations to be met can prove quite valuable when trying to hit aggressive solutions from product development milestones.
refer to: http://embedded-computing.com/articles/the-not-code-quality/