Prototype to production: Industrial controller requirements

Article By : Jacob Beningo

In this instalment, we present five high level requirements for the IoT industrial controller that will be prototyped in upcoming articles.

When I hear the word industrial controller, images of motors turning, algorithm churning, and bundles of wires feeding configurable green connectors come to mind. Industrial controllers come in many different types and flavours but as I consider this project on rapid prototyping an IoT industrial controller, I envision the capability for monitoring HVAC systems, controlling drive motors, relaying sensor data to the cloud, and rapid reconfiguration for an endless array of applications. As one might imagine, generating any type of requirement for a nebulous, evolving system that exists only in the foggy brain of developer can be quite difficult, but here's a stab at them.
(WARNING! My intention in this article is to consider a few general, high level requirements or features that an IoT industrial controller could have. It is by no means an attempt to develop a rigorous and complete set of requirements for an IoT device.)
Many great examples exist on how to develop requirements, such as the IEEE Swebok (Software engineering body of knowledge). Requirements tend to be refined constantly and creep as more information about the application, hardware, and general constraints become understood. At the beginning, every pie-in-the-sky requirement could be valid, but some will fade when cost and timing constraints are applied. For the reasons just stated, here are five high level "requirements" for the IoT industrial controller that will be prototyped in upcoming articles.

Requirement #1 – Simple to program without specialised tools
A generic IoT controller that can be used in any number of possible applications needs to be easy to program and update without the use of specialised tools or knowledge. This already presents a challenge. Opening up a device to access a JTAG port, for instance, is time consuming and potentially dangerous depending on the application. Programming a device through a bootloader could be a possibility, but once again many bootloaders require custom design and still require software to handle the update process.
One possible solution would be to design the system such that the program files can be easily dropped onto the controller like it was a thumb drive. Some development kits that use OpenSDA, for instance, allow for compiled programs to be easily dropped on a development kit, and then an internal bootloader updates the firmware. The problem here again is that this approach would still require potentially expensive tools to develop the software and would require specialised knowledge of the controller electronics.
An interesting alternative would be to have the controller run Python. Python is free, easy to learn, and once a script is developed it can simply be dropped onto the controller for execution. Since I've heard of elementary schools teaching Python in class, Python would be an intriguing language to use to develop an IoT industrial controller.

Requirement #2 – Contain typical industrial communication interfaces
There are many different types of interfaces that can be found on an industrial controller. General input and output with isolated and non-isolated signals is fairly common. The ability to control at least a single H-Bridge for motor control is useful as well. The more interesting communication interfaces in use are CAN, Ethernet, and Modbus. Occasionally some controllers will even bring out SPI and I2C. Many or most of these should probably be included in this project.

Requirement #3 – Support popular connectivity interfaces
The real point of an IoT industrial controller is to gather data and control hardware remotely. That is what makes the whole connected device idea so intriguing. There are a couple of very obvious communication interfaces for the connectivity, such as WiFi and Ethernet. An alternative might be cellular, but since most applications wouldn't require it cellular would be more of an add-on. Bluetooth Low Energy would be an interesting interface for local control. The use of Zigbee could be used to coordinate and control an entire network of local devices. Each of these interfaces would make an interesting addition.

Requirement #4 – Use HTTP and or JSON to communicate with the cloud
A quick Google search reveals that there are many possible protocols to use with an IoT device. Lots of them are competing, and only God knows which will survive in the long run. Anyone considering developing a product that needs to connect to the web and do so for the next 7 – 10 years, then, needs to select a protocol that is tried and true and will still be around in that timeframe. Http and JSON are two options that could be considered to connect a device to the Internet and stream control and acquisition messages.

Requirement #5 – Be hardware expandable
A general controller is never going to be able to fit every possible imaginable need. The ability to add on hardware through Modbus or remotely via a mesh network would be intriguing. Sometimes though, you simply have to add a local sensor, so having the ability to add a small electronic board can be very helpful. The use of Arduino shield connectors, while not really suitable for industrial applications, could still provide the potential for rapid prototyping and adding in low voltage sensors.

Conclusion
The actual list of requirements that would be associated with an IoT industrial controller would be quite large and impossible to discuss in much detail in a blog. The five general requirements that we just discussed should provide some starting point guidance. In many cases requirements aren't fixed and continually evolve throughout the development cycle. Taking an iterative approach to requirement development can be highly beneficial.

About the author
Jacob Beningo is a Certified Software Development Professional (CSDP) whose expertise is in embedded software. He works with companies to decrease costs and time to market while maintaining a quality and robust product.