The first article of the Architecture Made Easy series mentioned that two major types of automation systems exist: control
systems, which live in the tangible world of physical objects, operating mechanical equipment like flying a B-2 bomber (which is far too complicated to fly without a computer); and information
systems, which cross into the world of intangible ideas and concepts.
Among these two types of automation systems, the disciplines of design and automation appear to go in completely separate ways. From a process perspective, these two types of automation systems
truly belong to distinct paradigms having about one hundred fundamental differences between them. As I said at that time, that is a different and exciting story. This is that story.
Data Architecture
As we learned from the first article, from a data modeling perspective, control and information systems are not fundamentally different; they just abstract things differently. More precisely, in
control systems, we do not have a need to abstract anything at all, whereas in information systems, we abstract many things at many levels, for both process and data.
From a data modeling perspective, control systems inherit concrete physical objects that occasionally differ in their names, while information systems inherit ambiguous language-based names that
can vary widely from one individual to the next, not only with their vocabulary, but with the way in which each individual abstracts an idea before labeling it with a name.
Existing engineering disciplines, such as normalization, reorganize attributes to minimize the redundancy of data values, but offer no ability to alter an abstraction or render a consistent set of
abstractions among multiple disparate ones.
As a result, the data architecture and design of control systems is a simple engineering exercise of modeling the few data attributes of each physical component, while the data architecture and
design of information systems is orders of magnitude more intense as the number of data attributes, their potential abstractions and the interrelationships that result. (See Architecture Made Easy: Rules of Abstraction.)
Functionality
Control systems deal solely with the tangible world, often involving the development of specialized hardware that performs a physical mechanical process. Control systems frequently deal with a
small variety of attributes, although those attributes sometimes occur in large quantities, such as with anemometer or altimeter readings that may provide a continuous stream of sensor data.
An example of a simple control system would be the software operating a modern vending machine. It accepts money, determines denomination, authenticates currency, facilitates a product selection;
tracks inventory, product price and gross receipts; routes product for delivery; and makes change.
An example of a hybrid control system and information system is the automated teller machine, like the ones developed by Barclay’s Bank in 1967, with a CPU, card reader, PIN pad,
crypto-processor, display monitor, function keys and a vault. The control system part took the place of the human physically interacting with the customer, while the information system part
interacted with the databases that tracked customer balances and their associated transactions.
In comparison, information systems typically include little or no custom developed hardware, and perform intellectual processes, as compared to physical ones.
Development Issues
As you may have guessed, object-oriented methodologies originated with control systems, where objects are extremely easy to identify.
Control systems usually have the following development issues associated with them:
- Frequent emphasis on custom hardware
- Environmental event driven
- Real-time processing is often required
- Often are computation/CPU intensive
- Volume of software code is moderate
- Variety of data attributes is low
- Data value frequencies are often high
Information systems, on the other hand, have the following issues associated with them:
- Emphasis is on custom software
- Mostly man machine interface driven
- Online and batch processing
- I/O intensive
- Volume of software code is high
- Variety of data attributes is high
Perhaps one of the most interesting differences in the programming of control systems versus information systems is the way in which they perform error handling.
Imagine the flight software of a B2 stealth bomber encountering a zero divide error during a mission. The last thing you’d want is for the software that is flying the aircraft to suspend
its activities so that it could take a dump to allow a programmer to find the error.
As a result, when a control system encounters something like a zero divide error, it usually goes to great lengths to rapidly ignore the problem so that processing may continue uninterrupted
without a would-be delay.
In contrast, when an information system encounters an error, such as a zero divide error, it automatically terminates with a diagnostic dump to better facilitate the root cause of the error. With
an information system, the primary concern is to protect data integrity and the quality of the information, and stopping its processing is a minor price to pay to protect information, particularly
when it involves financial data.
Differing Paradigms
Just as there are people that are more comfortable focusing primarily on process while others focus primarily on data, so are control and information systems.
Control system analysis and design are dominated by a process-oriented focus, with an emphasis on control modeling to properly operate a piece of machinery.
Instead, information systems employ enterprise information architecture artifacts, such as a set of guiding data architecture principles, logical data architecture, physical data architecture, and
conceptual, logical and physical data models. However, the differences continue to become even more pronounced.
Information systems have a variety of features emphasizing the criticality of data integrity that control systems almost never have:
- Database backups and restores
- Forward recovery from backup
- Transaction rollback
- Distributed computing
- Distributed data
In contrast, control systems are physically centralized and not distributed, they are more response time critical, and they commonly employ sensory I/O devices.
Implementation Issues
When implementing an information system, one of the decisions typically involves the selection of an operating system. In contrast, when implementing a control system, the question is usually how
to design the custom operating system and develop the custom I/O drivers.
As a result of having such a customized environment, the control system has a unique set of test issues. Unlike establishing the various testing levels for an information system (such as unit test,
integration test, user acceptance, production and disaster recovery), the control system has a variety of program-specific integration and test environments.
- Host-based test beds
- Real-time closed-loop test beds
- Real-time open-loop test beds
- Operational test beds
- Production units
For information system readers, host-based tests depend upon a host platform that facilitates testing of the control system application; real-time closed-loop test beds are test environments that
provide feedback into the control system application; real-time open-loop test beds are test environments that do not provide any feedback to the control system application; operational test beds
test the control system in operation; and production involves deployment of the operational control system.
Financial Aspects
The primary costs associated with an information system involve the development life cycle, deployment, ongoing production support and subsequent maintenance.
Due to the enhanced custom nature of control systems, the primary costs also involve a significant manufacturing component:
- Product-specific hardware
- Operating system SDLC
- Firmware development life cycle
- Test bed development
- Various types of system tests
- Operational testing
- Assembly line development
- Manufacturing of production units
- Deployment of production units
- Maintenance of production units
Similarly, the profit areas for information systems are typically sales and licensing copies of software, as well as the associated maintenance of the software.
In comparison, the primary control system profit area is in hardware unit production, and sometimes in maintenance and support agreements.
Hybrids
The reason that the distinction between control systems and information systems is becoming so topical is the emergence of hybrid systems. All around us there is a new generation of systems being
developed that are embedding control systems into information systems, and embedding information systems into control systems.
Although the examples are numerous, none are so clear as the emerging market of artificial intelligence driven robotics, where software not only operates the hardware, but where software also
operates the software to create an autonomous control system.
While most robotics control system information, system hybrids do not resemble the human form, as they are designed to perform specialized commercial activities. There is also a growing industry of
robotics that intentionally imitate the human form.
These are the ultimate hybrid systems; and as developers recognize the different paradigms of control systems and information systems that comprise these systems, their sophistication and utility
will improve, but that is another story for yet another article on information architecture for artificial intelligence.
Please let me know if you enjoyed this article, and don’t hesitate to let me know which articles in the “Architecture Made Easy” series are useful to your organization. In
addition, corrections, enhancement, and suggestions are always welcome and are requested.
