Book report: Advances in Systems Engineering
Yes, this is the best quality image I could find of the cover.
I have something of a love/hate relationship with Systems Engineering (SE). On one hand, I believe having that “thousand foot” perspective on a system is extremely powerful, helping to answer not just the question of how to best design and build a given widget, but which widget is even the best one to build. On the other hand, SE can lend itself to generating a ton of documentation that ends up sitting on a shelf somewhere doing no one any good. Personally, I believe that unless SE is tied to a model or simulation (so-called model-based systems engineering) it has extremely limited use; a static document is only good for that snapshot in time and has no strong connection to the actual engineering process as it evolves, save for maybe a particularly zealous and diplomatic systems engineer.
Having said all that, I felt it only prudent to keep track of how SE has, as the title suggests, advanced since grad school, both to keep my own knowledge up to date and perhaps to get some ideas for my own projects. So, when I saw the AIAA had a sale on Advances in Systems Engineering, how could I say no?
In total, there are six chapters spread out over about 300 pages. As I’ve noticed with many academic books, the chapters each read a bit more like independent journal papers than a cohesive single text. Still, there are multiple instances of a chapter referencing another in book, so clearly the authors collaborated during the writing process. It may just be a bit jarring for people expecting more of a textbook style of writing.
Given this structure, it probably makes the most sense to review it chapter by chapter, especially since there aren’t that many of them.
Chapter 1: System of Systems Integration: Fundamental Concepts, Challenges and Opportunities
This chapter does pretty much what it says on the tin. Part of what makes talking about systems, and by extension systems of systems (SoS), is the definition of a system itself. I prefer the idea of “a collection of physical and/or virtual components that rely on each other to function, and without any of which functionality is degraded”. It’s not a perfect definition, but I believe it captures the main points. So what distinguishes this from a SoS? The idea, loosely, is that the components of the SoS can function independently, but also have a role in the larger system. So think of the internet, which I think I could uncontroversially claim as humanity’s greatest SoS. If I have a computer, there’s a lot I can do with it without the internet. However, by having it join that larger system, my computer becomes a much more valuable resource, and the internet itself gains value as well.
Now, there’s a sliding scale here. The internet is highly decentralized, but there exist other SoS (like GPS) that would still fall under this umbrella, but are more centrally controlled and whose single points of failure are more acutely felt. This chapter does a good job of describing the spectrum between systems and SoS.
There is also a discussion of the ways to describe SoS via SysML-style diagrams and the processes by which SOSs can be designed for integration. Honestly, I’m not a huge fan of most visual modeling schemes, as I don’t find them particularly easy to interpret and, again, without a closer tie to modeling and simulation, I think they have inherently limited use. I did, however, like the discussion of interoperability. Perhaps obviously, this is a critical feature of systems operating within a SoS (think HTML standards for the web), but is not without its hazards of security and privacy. Mostly importantly, it’s easiest to implement from the start, and trying to shoehorn interoperability into a system that was never built for it can be - and often is - extremely painful. I appreciated that interoperability was treated this way, as a critical enabler for SoS integration, but by no means a panacea. Overall, a good chapter, if not one meant for a specific audience.
Chapter 2: Advances in Sociotechnical Systems
So what on Earth is a sociotechnical system? Even as I’m writing this, I’m getting red squiggly underlines on “sociotechnical” as a word I clearly either made up or misspelled. But to answer the original question, sociotechnical systems is a recognition that engineered systems don’t exist in isolation, but are inextricably linked to humans, and society more generally. Both acceptance (and therefore, commercial success) and the consequences of adoption of the technology are aspects of the system that should be considered during its development.
This is not exactly a simple task, as you may have noticed that human behavior is exceedingly difficult to predict. Still, the chapter offers some approaches for how to model or consider human behavior in the design of a product. This is especially important for some systems, like mass transit or emergency evacuation planning, for whom human behavior is a critical part of whether the system will behave as intended.
Pennock, M.J., and Rouse, W. B. (2014), “The Challenges of Modeling Enterprise Systems,” Proceedings of the 4th International Engineering Systems Symposium, Hoboken, NJ, 9-11 June 2014.
Oddly, what I’ll probably remember most strongly from this chapter is this flow chart. It may be odd to get a life lesson from an engineering diagram, but this came pretty close. The reason this struck me so profoundly is because as much as I’ve used optimization in professional engineering settings, I’ve also applied it in various ways to my own life. This is something I see many of my engineering friends (and some less technical ones) doing as well. In my own life, I’ve spent a maddening amount of time just trying to figure out the “best” plan for a day or weekend, only to spend most of the day I might have enjoyed instead paralyzed with indecision. The problem is that optimization, per this flow chart at least, is just one of several options, and perhaps most importantly, it may in fact be the wrong approach. In an engineering setting, there’s a decent chance that you can meet the requirements on the chart for the optimization option. But frequently in engineering, and even more frequently in day-to-day life, we simply can’t. Will I enjoy a social outing? Who should I try to be friends with? Where should I live in my metro area? These are questions that simply cannot be optimized, but they are questions that you can either take in stride (adapt) or make so as to give you convenient options in the future if it’s not something you enjoy (hedge). Or, if none of this is possible, you can even give yourself permission to turn out wrong, knowing that a decision made was better than no decision at all (accept). I found this flow chart valuable as a mental model, and for illuminating that there is more than one (particularly stressful when misapplied) way to approach the decision making process.
Chapter 3: Engineering Resilience into Human-Made Systems
A very interesting, if not extremely dense, chapter. The author focuses on a few case studies of systems which succeeded or failed to be resilient in the face of some disaster. This ranges from the 1906 San Francisco earthquake and its resulting fires, to the 2001 World Trade Center attacks, to the 2010 eruption of the Icelandic volcano Eyjafjallajökull. The chapter covers some broad resilience principles; state transitions as systems move from fully functioning, to partial function, restored function, or failure (among many other states); and finally how systems can be set up for resilience.
While, admittedly, I couldn’t now list off for you the resilient principles the chapter covers, it was an aspect of SE I hadn’t been exposed to much in the past. While it may not be of critical importance to every engineering project, there are still plenty where it is. Even something we might not consider safety critical like cell phones have still caused injury in past due to battery failures. I suspect the resulting losses due to replacements and refunds, and the damage to brand image, were disasters in their own way. And even if product failure won’t result in loss of life or injury, building more resilient and durable products sounds like a good idea to me. Hopefully, we’re past the age of planned obsolescence, but I digress.
In all, not the easiest chapter to get through, but an interesting perspective on how to plan for things not always going the way we intended. And how we should probably give it more thought.
Chapter 4: Applying SysML and a Model-Based Systems Engineering Approach to a Small Satellite Design
Of the chapter titles and short descriptions I saw before buying this book, this chapter was probably the one I was more interested and excited about. And probably for good reason it turns out. While I’d heard of SysML (Systems Modeling Language) and its parent language UML (Unified Modeling Language) before, I hadn’t really seen them in action or learned much about what they set out to accomplish beyond the most general “represent systems diagrammatically”.
As it turns out, it’s quite an ambitious undertaking. SysML seeks to capture four main varieties of system interactions:
Structure - The physical interactions between elements of the system
Behavior - What are the sequences of states the system will pass through, or how will the system’s controls be structured.
Requirements - What are the requirements of the system, and how will their pass or fail criteria be measured
Parametrics - How are the responses of the system mapped to its outputs? So for instance, the mass of an object might be parameterized as mass = length * width * height * density. This allows various designs to be evaluated for how well they meet requirements or how they behave.
I should mention that although both these “four pillars” of SysML seem to be standard, this chapter also includes a fifth variety, the “Package” diagram. From my understanding, this is sort of a meta-diagram, showing the resources that the model is built on. Also, in my quick rereading the chapter to summarize it, I realized there’s some issue with heading formatting, so hopefully something future editions will address.
On top of that, the chapter discussed how these sorts of models can be used to avoid the SE documentation trap. The idea is that instead of providing a static document that may be quickly rendered outdated, SysML provides a mean to stitch together otherwise unconnected analyses and toolsets. In theory, it can provide a framework through which larger team interactions and engineering activities can be coordinated.
I say theoretically because SysML is “just” a language standard. For instance, just because French has a language institute that monitors and formally standardizes the language doesn’t necessarily mean that word processors exist that properly implement those standards, or that one can easily input a “ç” or “ô” on a given keyboard, or even that those characters will render properly for everyone. For SysML, there seems to be great difficulty in finding software that allows users to create SysML diagrams with the full expressive power of the language. And that’s before addressing the issue of interoperability with other software tools, which appears a bit hit or miss.
Do I think SysML is “the answer” to SE? No, but then again I’m not much of a believer in silver bullet solutions in general. I think it brings up many good concepts and approaches, but I feel from what I’ve read of the standard and its future direction that they’re running the risk of getting bogged down in implementation details. I’ve also heard criticisms of SysML that it’s become overwrought and too visually complicated to be easily parsed.
All that said, I found this chapter very thought provoking, and while it may not lead me down a path of SysML evangelism, it’s given me several ideas I’d like to pursue further.
Chapter 5: A Systems Engineering Approach and Case Study for Technology Infusion for Aircraft Conceptual Design
Wow, was this chapter nostalgic for me. The two authors (Drs. Griendling and Mavris) represent the lab I got my Masters degree from at Georgia Tech, with Dr. Mavris having been my graduate advisor. As a result, I saw a lot of familiar approaches in this chapter, things like Quality Function Deployment, parametric sensitivities, metamodeling, quality of fit metrics, technology k-factors, and a number of other conceptual design approaches.
For those unfamiliar with it, this chapter would be a great introduction to the Georgia Tech Aerospace Systems Design Lab’s “patented” SE approach. And it’s not a bad one, I’ve used elements of it in my engineering work over the years and it’s quite effective. It provides a wide initial view of the system, and allows teams to narrow down their conceptual design until they can find one or several design candidates to investigate with more detailed engineering.
But similar to how SysML is no silver bullet, neither is this approach. It’s a bit too manual for my tastes, and while the Aerospace Systems Design Lab (ASDL) isn’t a software developer, I do wish this approach were more closely linked to software tools that would automate it where possible. I also feel like it can be difficult to scale due to its reliance on expert and shareholder consensus in some stages. Additionally, it doesn’t provide any inherent improvement in how an organization functions (although it can be used to do so) and also effectively “hands off” the candidate conceptual designs to the engineers doing the detailed design. But again, there are no silver bullets, and the process can be a significant improvement over how an organization currently does their engineering work.
Also, on a more personal level, I was hoping to see how far the ASDL’s approach had come over the years, and it’s largely the same as I remember it being roughly a decade ago. The chapter points out some tweaks they’ve made to overcome some approximations in earlier iterations of the process, but I’m not sure I can even remember what they were at the moment. Still, conceptual design is a critical part of SE, without which one runs a much higher risk of extremely expensive design iterations only to end up with a suboptimal product.
Overall, I thought it was a well presented chapter, and for all my criticisms, would still highly recommend people read it.
Chapter 6: Powerful Opportunities to Improve Program Performance Using Lean Systems Engineering and Lean Program Management
This was a relatively short chapter, but a good way to wrap up the book. While I feel like “lean” is a bit of a buzzword, the chapter was an interesting view into issues with government contracting, as well as the places where “classical” SE has fallen short in practice. Perhaps most interestingly, it notes how the traditional SE “Vee” has been modified by SpaceX, and how those modification have allowed that organization to develop innovative products at record speed and cost. It’s something I’m looking more into, as the modifications made to keep the Vee alive are sometimes quite extensive.
Source: https://www.ppi-int.com/the-wedge-model/
It’s easy to sit on the sidelines and snipe at those putting work out, but this all feels to me like slapping band-aids on an abstraction that just isn’t holding up. It feels a bit like my own code in a way; when it starts getting overly complicated and hard to follow, it’s almost always because I’ve missed a better, simpler approach earlier in the process. A short presentation I found comparing and contrasting traditional SE vs SpaceX’s version can be found here.
I’m looking forward to not only seeing how the Vee process evolves, but to reading about the work that has been done in this area, and how tools can better capture it in the future.
So in summary, was it worth the effort to read Advances in Systems Engineering? Yeah, I’d say so. Like with anything your mileage may vary, but if SE is an interest of yours, I’d suspect there’s something you’d find new and interesting. For me personally, this book provided the seed of an idea for how to tie together the various projects I’ve been working on, in particular Chapter 4 on SysML. More on that later I’m sure, along with the other, seemingly unrelated reading it’s spurred for me. But for now, go forth and optimize, adapt, hedge, or just accept :-)