There is no doubt that ours is an increasingly cyber-physical society. That is, we are more and more dependent on complex “smart” systems (cities, houses, vehicles, electricity grids, internet of things, etc.), all of which are used to control our world to make it more amenable to human needs. A salient illustration of this trend is the “Smart Anything Everywhere (SAE)” initiative, which is an integral part of the European Commission ‘s Horizon 2020 advanced research programme. Its objective is to upgrade “products and services to the digital age” (https://smartanythingeverywhere.eu/).
The term “cyber-physical” is a relatively new one and is used to denote “an integration of computation and physical processes” . However, this potential for synergy between information technology and physical devices has been obvious from the very earliest days of computing technology. At this point, we are at a stage where the latest hardware and software systems can provide capabilities that could only be dreamed about when Norbert Weiner introduced the term “cybernetics” over 70 year ago.
At that time, the desire and need for automated control of physical processes led to the new engineering discipline of automatic control. This discipline quickly developed a solid theoretical foundation based on the classical principles of engineering through the use of physical and mathematical modeling. This foundation was further extended to cover the emerging computing technologies with sampled-data approaches.
With the self-evident complementarity of computers and control theory, one would expect that the software engineering and automatic control communities would be highly integrated and working in close collaboration with each other. Unfortunately, after close to five decades of industrial experience in both domains, my sense is that this is not the case. Moreover, there seems to be little interest among many to bring them closer together, particularly among those involved in research (where one would normally expect the collaboration to be most intense).
As a case in point, not too long ago I had an interesting exchange with the project lead of a large “smart grid” research project. This was a major government-funded research initiative with a budget that ran into hundreds of millions of dollars. This particular individual is a highly regarded professor, widely recognized for his world-class research in control theory. I asked him how he saw the role of software in this project. He responded with “oh, you mean the data side” (my emphasis). In other words, his perception of the primary purpose of software was to perform ancillary “data processing” functions, such as accounting, logging, archiving, and the like.
Nor was he alone in this view. It emerged later that all other members of the research team – all of them experienced and highly capable researchers in various classical engineering disciplines (electrical, control engineering, etc.) – shared this distorted opinion. In fact, no individual on the team had extensive experience with or expertise in software engineering. At best, software is perceived as a power-assist augmenting individual “real engineering” components by adding a bit of “smarts” to them.
This skewed perception of software and its role is one that I have encountered a number of times, particularly in the automotive sector. This is a domain where the primary responsibility for the technical design belonged, quite understandably, to mechanical system engineers. However, over time the amount and complexity of software in modern vehicles grew by orders of magnitude (the software in some modern vehicles exceeds a hundred million lines of code). From initially replacing simple relay-based logic, the software in these systems rapidly became all encompassing. For example, the current AUTOSAR standard for automotive systems  was specifically designed to integrate the different software components in a vehicle into a single unified system. This has, unfortunately, created a whole new category of problems stemming from unforeseen couplings between previously independent automotive functions, exacerbating further the already deplorable industry-standard defect rate for large software systems1. Consequently, software had become a primary source of defects many of them resulting in expensive vehicle recalls. Fortunately, with the recent focus on autonomous vehicles, in this domain software is now increasingly viewed as an integral part of system design at the highest level. However, as my power-grid example suggests, this has yet to be adequately recognized in other domains.
Lest the foregoing might lead to conclusions that the problem lies exclusively with attitudes and culture of classical engineers, it should be clear that the software engineering community is at least equally to blame, if not more. Namely, as the youngest and, in many ways, a unique technical discipline, software has evolved a culture that has little in common with traditional engineering. Its novelty has misled many of its practitioners into thinking that there is nothing particularly relevant to be garnered from classical engineering theory and practice. For example, the concept of agile development, which has been practiced in traditional engineering from prehistory, has been re-invented (as a completely “new” idea2) by software “gurus”, and then further corrupted by its practitioners. Thus, one of the precepts of the “Agile Manifesto”  , states that there should be “no big up-front design” at the start of a software project, on the assumption that a good design will emerge as the implementation proceeds. (While this approach might work for small-scale software systems, it would definitely lead to catastrophic failures for large systems such as those needed for autonomous vehicles or smart grids.)
Moreover, the lack of contact with and cross-fertilization from disciplines such as control engineering, means that a multitude of software practitioners are unaware of some common engineering design patterns that are highly relevant in their domain. One salient example is the principle of negative feedback. After all, the reasoning goes, software is used for control, so while it may be a part of an automatic control system, this principle does not apply to the software itself. Yet, in my 40-plus year industrial experience, I have seen great value precisely in exploiting feedback control to the control of the software itself, especially for large (and, hence, buggy) software systems3. These systems consist of many different subsystems, whose functionality has to be properly initialized and synchronized. This can be a very complex task that needs to be carefully worked out. Furthermore, because software is so highly error prone, there is a need to quickly detect and recover from failures – whatever their cause. This is precisely the kind of problem that feedback control was designed to solve. It is particularly applicable for the coming generation of large cyber-physical systems, where it is finally being recognized that there is a need to devise designs capable of dealing with uncertainty stemming from the inevitable “unknown unknowns”  inherent in such systems.
Similarly, the fundamental control concept of observability is poorly understood in this community, where it is often perceived as a matter of debugging. Yet, given the transhuman speeds at which software executes, it is hard to imagine a more critical category of systems in need of greater observability. For example, it is quite common for software designers to be surprised when – by means of specialized execution profiling facilities – they are presented with information on what their systems are actually doing.
In conclusion, it seems clear to me that it
is high time for the theoreticians and practitioners involved in both
disciplines, currently operating as “two solitudes”, to come together and learn
from each other in what should be a natural synergy. To do otherwise, would be
 E. Lee, E. and S. Seshia, Introduction to Embedded Systems, A Cyber-Physical Systems Approach, Second Edition, MIT Press, ISBN 978-0-262-53381-2, 2017.
 M. Zhang, T. Yue, S. Ali, B. Selic, O. Okariz, R. Norgren, and K. Intxausti, “Specifying Uncertainty in Use Case Models”, Journal of Software and Systems Modeling, (pp.573-603), October 2018.
 S. McConnell, “Code Complete: A Practical Handbook of Software Construction” (2nd ed.), Microsoft Press, 2004.
 “Manifesto for Agile Software Development” (https://agilemanifesto.org/), 2001.
 B. Selic, “Recursive Control”, in R. Martin, et al., Pattern Languages of Program Design 3, Software Patterns Series, (pp.147-162) Addison-Wesley Longman Inc., 1998.
 D. Garlan, “Software Engineering in an Uncertain World”, Proc. FSE/SDP Workshop on Future Software Engineering Research, (pp.125-128) 2010.
Bran Selić, Malina Software Corp., email@example.com
1 Estimated at between 15 and 50 bugs per 1000 lines of code 
2 In that vein, there is a famous saying by Mark Twain: “The Ancients stole all our good new ideas”.
3 This is a variant of the problem captured in the age-old problem: “Who takes care of the caretaker while the caretaker is busy taking care?”