Search

Systems and Software Engineers often have an uneasy relationship. The job of the systems engineer is to work with the stakeholders to define a set of requirements that meet their needs. These are then allocated to various solution spaces such as electronic hardware, mechanical, procedural, and software among others. For many systems, the functional requirements are almost exclusively software requirements. Correspondingly, as an increasing amount of project manpower, schedule time, and budget are allocated to software, it becomes increasingly important that systems and software engineers communicate effectively. The Systems Modeling Language (SysML) has helped in this regard in that it can provide executable behavioral models with precise semantics to express software requirements in a model. These models define "What is required" without overly constraining the implementation. In addition, SysML can be used to define performance constraints, required concurrency, hardware memory and processor budgets, interfaces, safety critical requirements, etc. These aspects are essential for software engineers to understand the constraints and limitations of their environment. At the System of Systems (SoS)/Enterprise level, defining software/systems employs a similar pattern, but at a higher level of abstraction. In the Unified Architecture Framework, capabilities are defined for the enterprise, with systems and software allocated to realize the capabilities. In the same way that capabilities depend on one another, the implementing systems and software interact to support each other. In the past, enterprise software would be modeled as residing in mainframes in a federated software pattern. Modern software can be modeled throughout the enterprise in a distributed network that can adapt to the changing needs of the enterprise to do load leveling, dynamic and late binding, reconfiguration, and reallocation of hardware resources as necessary. If the domain includes the Industrial Internet of Things (IIOT), then deployment could include edge devices, embedded software, Programmable Logic Controllers (PLC), PCs, servers, cloud computing, and of course mainframes. The Object management Group (OMG) Data Distribution Services (DDS) standard enables these capabilities across these devices in a universal format implemented by multiple vendors. However, before this complex system of systems can be implemented, it must first be architected and designed to ensure that it will be fit for purpose both now and as the complex system of systems expands and evolves. This paper will examine the aspects of modeling software in the UAF, and how it can help guide enterprise and system and software architecture. [ABSTRACT FROM AUTHOR]

The global supply chain is a complex system of systems made up of and relying on other complex systems of systems (SoS) to achieve its goals. To take a typical example, Enterprise A is supplied essential parts on a regular basis to manufacture its products. To place the order requires global financial systems, integrated email systems, the internet, multiple telecommunications systems, and supply software provided by large companies. To deliver the parts may require air and maritime transportation systems, the rail network, interstate highway systems, road haulage companies, state and local transportation systems and so forth. When any of these complex systems fail, the impact can be global, and the results catastrophic. Recent examples include the shortage of Personal Protective Equipment (PPE) during the COVID pandemic, computer chip shortages delaying the assembly and sales of cars, and, most recently, the baby formula shortage. These were due to disruptions in the supply chain caused by an overreliance on single sourced suppliers who failed to deliver, transportation disruptions, outsourcing of critical parts, supplies, medicines to distant countries, and/or an overreliance on "Just In Time" for inventory management. This is the case of placing too many eggs in too few baskets, and often just one basket. Counterfeit or substandard parts and products can enter the supply chain via graft, breaks in chain of custody, or carelessness. This has included critical mechanical parts on aircraft, chips containing spyware, and substandard or out of date medicines substituted for the real thing resulting in serious illness and death. This complex SoS needs to be examined, studied, and understood in the same way as a mission critical system; threats, vulnerabilities, and risks need to be identified and mitigated and assurance cases defined to ensure a solid and reliable supply chain. This paper will look at the supply chain of an example factory system to determine how some of these problems can be predicted, prevented, mitigated, and solved using the UAF, RAAML and assurance case techniques. [ABSTRACT FROM AUTHOR]

When planning and conducting a Mission Engineering (ME) study, it is important to have a complete, correct, and coherent model of the mission architecture. The Unified Architecture Framework (UAF) has been found to be effective for this purpose. The OUSD (R&E) Mission Integration office is exploring how to use UAF for their ME architectures. This paper will explore some of the required modeling features and constructs that will enable this to occur. The paper "Implementing Mission Engineering with UAF" was presented at a previous conference and this paper will expand on that presentation and will discuss additional work that has been accomplished since then. This paper will also explore the proposed extensions for UAF to better support ME. We created a prototype model using the Battle of Hoth from Star Wars as a proof of concept for these modeling extensions and used the process and ME concepts defined in the Mission Engineering Guide (MEG). Since then there have been several concepts that were explored such as compatibility with the Model‐Based Acquisition (MBAcq) approach, recent initiatives from the Office of the Assistant Secretary of Defense for Mission Capabilities, Enterprise Systems Engineering (ESE) process and methods, detailed resource engagement, use of different modeling languages (e.g., Systems Modeling Language (SysML), SysML v2 and UAF v2), Effects and Outcomes, variety of measures, additional attributes/stereotypes such as differentiation between enemy/friendly/neutral ‐ Blue Force, Red Force, etc., provenance/confidence of enemy resources, and so forth. This paper will summarize the research and modeling done to date and explore these additional concepts as well as new ideas introduced in the MEG v2. [ABSTRACT FROM AUTHOR]