Executing a successful program to develop on time and within budget has always been a tremendous challenge for government agencies and partners in the aerospace and defense (A&D) industry. With today’s relatively flat economy, globalization, product sophistication, and the continuing emergence of new technologies, the level of complexity in A&D product development is now staggering.
Additional obstacles that complicate the environment in which an A&D company develops are complex contract vehicles, complex systems of systems, cutting-edge design and large supplier networks. This reality is not going away in the near future.
Collected research from ASME, Pricewaterhouse Coopers, Georgia Tech University and the AIA all point to interesting trends in Aerospace. These include:
- The rise of system software for which airborne software is dependent
- Craft-to-craft communication
- Increased need for data handling and the IoT
- Aircraft becoming flying computers and antenna farms
- The need to revise aerospace engineering education
With the rise of unmanned systems with more and more computing capability being built and deployed for military, government and commercial purposes, size, weight and power (SWaP) are at a premium.
Modularization, small form factor and ruggedization are example means to address the requirements of minimizing size, weight, power and cost (SWaP-C). Design teams are putting more and more software apps on a single platform. Often, these apps come from several suppliers with the need to further manage complexities at the software system level.
Successfully executing the development of a system today with such obstacles and trends stretches the capabilities of engineering teams. It used to be that mechanical engineering teams working with electrical engineers could successfully produce new systems, even complex ones. It is also no longer possible to expect engineers to have enough engineering domain experience across all disciplines.
Today, with products and systems now dominated by software, and products being more of a system of systems, the complexity and coordination across engineering design has to be executed with precision.
It is increasingly more important for the systems engineers to coordinate this multi-team engineering effort. Model-based engineering is today fully in use across all domains, yet the models themselves (CAD, electrical, software, business and systems) are different from domain to domain.
Even though models are now more or less well known by engineers in their own domain, there are not many ways to communicate and integrate these models across domains. This leads to a lack of understanding of the overall system across engineering teams. This lack of understanding complex systems leads to increased waste, longer development times, increased risk, errors in testing and on and on. We need to fix the “on and on.”
This lack of understanding becomes especially problematic with more software going into A&D systems. Software systems engineers focus on include:
- Services and systems constraints
- Specification of software system structure and behavior
- The evolution of the software over time and across system families
System-specific software is on the rise. Airborne software is system dependent; software developers must know every aspect of the hardware with which it interoperates.
And software itself has many characteristics as development pioneer Winston Royce1 identified: Software is large; it solves or models complex mathematical and complex physical problems; it uses every available machine cycle and every storage bit (when finally completed); it is tailored to a single mission; it is embedded within a complex system of interacting hardware elements; it embodies significantly new functions never before coded in software; it has a stressful operating environment; it has complex interactions with highly trained users; its builders do not use it; its users do not build it; and its operation risks human life and great economic loss.
A timely quote: “Hardware and software have a symbiotic relationship, this means that without software, hardware is very limited; and without hardware, software wouldn’t be able to run at all. They need each other to fulfill their potential.”2
Systems engineers are increasingly challenged to better manage this interrelationship between system software and hardware. Problems become magnified when software teams develop according to Agile methodology. Systems engineers familiar with principles of maintaining a total system perspective throughout development can become confounded when software engineers leverage rapid innovation and creativity that Agile affords.
Boehm (2006)3 spoke about the increasingly complex systems-of-systems trend, saying that traditionally—and even recently for some forms of Agile methods—system and software development processes were recipes for “standalone stovepipe systems” with high risk of inadequate interoperability with other stovepipe systems.
The lack of a common denominator in such stovepipe systems collections may cause unacceptable delays, uncoordinated and conflicting plans, ineffective or dangerous decisions and inability to cope with rapid change.
On the other hand, Herbsleb (2007)4 reflects on an increasing global connectivity trend and describes a desired future for global development—plus the problems that stand in the way of achieving that vision. Herbsleb reviews research and outlines research challenges in four critical areas: software architecture, eliciting and communicating requirements, environments and tools, and orchestrating global development.
Requirements are supposed to be the “glue” that maintains the common thread between various engineering teams. Requirements themselves, even when purely expressed as requirements models can only go so far. Not everyone can read them. You can employ all of the best engineering tools in the world for your teams to use, but unless you include mechanisms that facilitate understanding, there is risk for misinterpretation or design specification mismatch resulting in unexpected delays and cost when integrating the software and hardware.
When developing or integrating an extremely complex system, techniques to measure and mitigate complexity are good practices for teams. These include:
- Leveraging more granular collaboration across teams and engineering disciplines
- Abstraction of system requirements into readable models
- Possibly using modular design patterns
Systems engineers themselves need to be the “universal translator” and “herder of cats” that ensures understanding is the same across all teams. Systems engineers also need to become more fluent in software engineering to understand their role.
Modern tools and techniques with built-in collaboration help engineers understand information, language and design across engineering domains. These solutions, in concert with a good systems engineer or team of systems engineers will help overcome the many challenges facing A&D.
- Winston Royce 1970. “Managing the Development of Large Software Systems”, Proceedings of IEEE WESCON 26 (August): 1–9
- Wikipedia – Fundamentals of Computer Systems: Hardware and Software
- B. Boehm. “A view of 20th and 21st century software engineering,” Proceeding of the 28th International Conference on Software Engineering, (ICSE ‘06), 2006
- Herbsleb (2007) “Global Software Engineering: The Future of Socio-technical Coordination” James D. Herbsleb