Blog Editor’s Note: We have not see a lot of papers about PNT governance (other than our own), so it was great to receive this one from our colleague Andy Proctor. He presented it at the Royal Institute of Navigation’s (RIN) International Navigation Conference in November. It will be published in the conference Proceedings.
We are glad to be able to share it here also and add a few words.
We particularly liked his mention of the Seven Pain Points of Systems of Systems, which we have reproduced below. This isn’t a spoiler as he discusses how to avoid or cope with them further in the paper. And there is a lot of other good stuff in there also.
SEVEN PAIN POINTS OF A SYSTEM-OF-SYSTEM
INCOSE in its System Engineering handbook (INCOSE, 2015) set out the typical challenges and conflict area between the SoS activities and the constituents. These are summarised and recounted below as “seven pain points” and must be addressed in any SoS development, especially in an Enterprise or Governmental setting.
- SoS Authority and Governance. In a SoS each constituent system has its own ‘owner’, stakeholders, users, processes, and business model. There is a heavy reliance on an agreed common purpose and motivation for constituents to work together towards collective objectives which may or may not coincide with those of the constituent systems.
- Leadership. The lack of common authorities and funding pose challenges for SoS especially for leadership, coherence, and direction in a multi-organisational environment.
- Constituent systems’ perspectives. SoS are typically comprised, at least in part, of in-service systems, which were often developed for other purposes and are now being leveraged to meet a new or different application with new objectives. This is the basis for a major issue facing SoSs; that is, how to technically address issues which arise from the fact that the systems identified for the SoS may be limited in the degree to which they can support the SoS.
- Capabilities and Requirements. Ideally engineering processes begins with a clear, complete set of user requirements and provides a disciplined approach to develop a system to meet these requirements. Typically, SoS are comprised of multiple systems with their own requirements, working towards broader capability objectives. Ideally the SoS capability needs are met by the constituent systems as they meet their own requirements, but in many cases the SoS needs may not be consistent with the
requirements for the constituent systems. In these cases, the SoS needs to identify alternative approaches through changes to the constituent systems or additions of other systems to the SoS. This is a significant challenge for PNT systems due to the diverse nature of the use cases where PNT is essential.
- Autonomy, Interdependencies and Emergence. An independent constituent system may change independently of the SoS, along with interdependencies between that constituent system and other constituent systems which adds to the, and introduces complexity or unknown elements in, the SoS. Specifically, this can lead to unanticipated effects at the SoS level leading to unexpected or unpredictable SoS behaviour.
- Testing, Validation, and Learning. The fact that SoS are typically composed of constituent systems which are independent of the SoS poses challenges in conducting end-to-end SoS testing as is typically done with systems.
- SoS Principles. SoS is a relatively new area, with the result that there has been limited attention given to ways to extend systems thinking to the issues particular to SoS. Work is needed to identify and articulate the cross-cutting principles that apply to SoS in general, and to developing working examples of the application of these principles. There is a major learning curve moving to a SoS environment, and a problem with SoS knowledge transfer within or across organizations.
Link to paper: DEVELOPING A PNT ARCHITECTURE FRAMEWORK
Andy Proctor, Royal Institute of Navigation and RethinkPNT. [email protected]
