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]

Hazard analysis for individual systems is a task that is required as part of the production of most complex systems to identify hazards and to take appropriate measures to alleviate such hazards. It is a laborious and expensive task that requires key specialists and lengthy analysis. This is not just for systems on their own. Since collaboration between systems is becoming increasingly important, this complicates hazard analysis even further. It requires a systemic process looking at the individual systems as well as the system of systems and the environment in which they operate. The example looks at the concept of platooning i.e., where trucks transporting goods can operate as a platoon, traveling very closely together under the control of a platoon leader. Platooning has the benefit of reducing traffic and harmful emissions but introduces new hazards that must be examined and mitigated. The paper describes an approach to hazard analysis for a system of systems (SoS) that uses a model created using the Unified Architecture Framework (UAF) as an aid in identifying and analyzing hazards. [ABSTRACT FROM AUTHOR]

The Digital Engineering Strategy released in June 2018 outlined the DoD's strategic goals which "promote the use of digital artifacts as a technical means of communication across a diverse set of stakeholders." Ultimately, by involving a variety of perspectives in the design decisions, one can increase quality and speed without increasing risks. "In addition to build, test, field and sustainment of defense systems, emphasis was placed on the acquisition and procurement of systems and the importance of digital engineering. This was further reinforced in the Feb 2022 release of the Engineering of Defense Systems Guidebook which contains Digital Engineering sections in each chapter. The norm for Systems Engineering has become Model‐Based Systems Engineering (MBSE) in which models are used at all phases of development. To complete the digital thread from concept to disposal, models will be required for the acquisition phase. This paper will describe Model‐Based Acquisition (MBAcq), and how it can be used to increase clarity for compliance and understanding in Systems and Software Acquisition." (Hause, Hart, 2022) MBAcq can supplant the use of document‐based specification but only if we come together as an industry to develop and agree upon some standardization. A word of caution, model‐based approaches will only be successful if they are grounded in sound systems engineering practices. The thought process to create the models are as equally important as the resulting models themselves. This paper will discuss the work being done by the OMG MBAcq User Group, which is a broad industry body with participation from INCOSE, Armed Services, OUSD, DoD CIO, NDIA, DAU, FFRDCs and many industry suppliers, such as Boeing, Northrup Grumman, and Lockheed Martin, working together to successfully create both the standardization and guidance to successfully deploy MBAcq to the larger community. Parts of this paper were first published by the authors in (Hause, Hart, 202) [ABSTRACT FROM AUTHOR]

Knowledge and experience are gained during the execution of every project. This knowledge remains in the heads of the engineers, but often is not distributed more widely. In Model‐Based Systems Engineering (MBSE) projects, this knowledge can include problem solving techniques, algorithms, libraries of types, patterns, interfaces, components, etc. One of the ways to preserve this knowledge is by creating libraries of these reusable assets. For example, the newest version of Unified Architecture Framework (UAF) included a library developed by Mitre of 1200 different security controls defined in National Institute of Standards and Technology (NIST) standard 800‐53r5. These controls can be referenced on projects to mitigate many common security risks. Each defined control can be integrated with the corresponding risks, security metrics, mitigating elements, solutions, and so forth. All these elements could then be used to construct Security Patterns showing risks that the security controls can mitigate as well as abstract solutions that can satisfy these controls. Patterns publicly provided as a curated, searchable, solution set library could be leveraged by projects and augmented over time, preserving their Intellectual Property (IP) and knowledge assets. This paper discusses these concepts and methods and demonstrates how they can be applied to improve system security. [ABSTRACT FROM AUTHOR]

Model‐Based Engineering (MBE) has transformed the worlds of mechanical, electrical, chemical, software, systems engineering, and now cybersecurity. Model based cybersecurity allows this concern to be addressed as an integrated part of the solution as opposed to being a separate solution. To best take advantage of this, we must examine which modeling practices, languages, and standards are best suited to handle cybersecurity. Currently, UAF is the most effective tool being used to provide Model‐Based Cyber Security at the Enterprise and Systems Level. It achieves this largely through its integrated security viewpoint as well as by facilitating capability‐based engineering. Furthermore, it allows modelers to integrate with other cybersecurity‐focused modeling tools to include cybersecurity in the digital thread. The INCOSE Future of Systems Engineering (FuSE) Initiative defined 12 key concepts including "Capability‐Based Security Engineering" and "Security as a Functional Requirement." This paper discusses these FuSE concepts and demonstrates how they can be effectively realized via the use of UAF and shows how UAF coupled with complementary tools and standards provides powerful verification and validation capabilities. Note that this paper is derived from INCOSE Insight articles Brooks, Hause (2022) and Hause, Brooks (2022) published in a special issue on FuSE Security. References are included below. [ABSTRACT FROM AUTHOR]

One of the most troublesome and challenging parts of systems engineering is that systems keep changing. Some changes are planned as part of a phased system rollout. Others can occur because of changes in the environment, technology, customer need, unexpected emergent properties, competition, discovered system vulnerabilities, etc. Regardless of why, the systems engineer needs to document these configurations as part of a digital thread leading to physical systems that will be manufactured and installed. When using SysML as part of MBSE, there are advantages and disadvantages regarding the modeling variability using inheritance and other structural modeling techniques. Elements in a so‐called superclass will be inherited by all members. This is advantageous for additive systems but can cause issues when configurations require removal of systems. This paper will examine system configuration over time showing how to model configurations and changes. It will also look at other techniques such as Product Line Engineering (PLE) with OVM and Feature Based Modeling. [ABSTRACT FROM AUTHOR]

It has been almost 20 years since INCOSE and the OMG kicked off an effort to create a standardized model‐based systems engineering modeling language. That effort culminated in 2006 with the creation of the Systems Modeling language (SysML). Over the past several years, numerous industries have increased their adoption of SysML and MBSE as a core practice within their engineering lifecycles. However, they have not achieved many of the originally envisioned benefits. On closer inspection, many of the challenges and barriers with which MBSE practitioners are currently struggling are remarkably similar to the problems seen in large DoD software programs from the 1970s and 80s and were resolved decades ago by the software development community regarding scale and complexity. System models are becoming larger and more complex. Yet, in this expanding and maturing MBSE environment, projects continue to experience problems with model integration, repository performance and model lifecycle management. It is time to go back and take another look at how the software community attacked problems of extreme scale. The similarity between MBSE's model management pain points and those experienced years ago by the software industry is not unexpected. Adoption of MBSE requires the replacement of the largely manual, document‐based engineering processes with a complex engineering information processing system. Unlike documents, the models produced by that system are living artifacts that require management over the project lifecycle and which have all the characteristics and complexity of software. This paper presents a framework for MBSE planning and model lifecycle management based on the key practices from Systems Engineering and Software Engineering to provide an actionable set of best practices that can be applied today to address current MBSE lifecycle management issues. We have organized these best practices around three key MBSE Model Management Imperatives. [ABSTRACT FROM AUTHOR]

As systems security joins the top concerns of systems engineering, the availability and affordability of already scarce security expertise presents a resource barrier and raises questions about the nature of competency needed in the systems engineering team. Workshops in 2022 exploring the eleven strategies outlined in the 2021 roadmap for Security in the Future of Systems Engineering revealed one strategy as centrally synergistic with all the other ten: Stakeholder Alignment. Investigating means and effects of aligning stakeholders on security requirements led to the understanding that security expressed as loss‐driven needs and capabilities would be accessible to everyone, independent of how those needs and capabilities would be realized. This article makes a case for achieving stakeholder security alignment as a means to efffectualize security as a foundational perspective in system design and actualize security proficiency in the SE team. [ABSTRACT FROM AUTHOR]

The Multi‐Orbit Disaggregated System (MODS) concept is a disaggregation strategy geared towards improved resiliency and flexibility of space missions by dispersing payloads and/or functionality across multiple small satellites (SmallSats). Although SmallSats make good candidates for deployment as a MOD System, their success hinges on the ability to realize reliable Inter‐Satellite Communication (ISC). To this end, we investigate the efficacy of developing a model‐based systems engineering (MBSE) Architectural Framework for ISC to guide and constrain instantiations of ISC architecture solutions. An MBSE architectural framework is a systems engineering artifact that defines a set of views required to describe an architecture based on MBSE principles and practices. It provides a standardized structure and guidance to capture architectural decisions while maximizing opportunities for commonality, consistency, and interoperability within the Domain of Interest. To achieve well‐defined architecture descriptions, a MODS architectural framework pattern, and a comprehensive architectural framework for the ISC (sub)system are created and presented. The Systems Modeling Language (SysML) (OMG, 2019) serves as the modeling language for the framework design. [ABSTRACT FROM AUTHOR]

To put it very simply, but not at all clearly, the 2021 Texas electricity grid failure was both caused by and not caused by the use of renewable energy. In 2020, 46 percent of Texas's energy was generated by natural gas, coal 18 percent, nuclear 11 percent, and renewables wind power 23 percent, and solar 2 percent. During the winter months when power demand is lowest, renewables can rise to up to 55%. When the historic winter storms hit, the biggest problem was the lack of winterization of all types of generation systems and supporting infrastructure. All the of the systems failed to various degrees. So why weren't these systems winterized? Mostly it was a lack of incentives. The government provided no financial incentives and did not mandate winterization. These winter storms were once in a century event, and companies could not make a business case with reasonable ROI to winterize. Companies that did manage to operate sold power and gas for up to 400% more than normal due to the lack of supply and increased demand. So, there was a built‐in disincentive to not invest. What happened was a complex system of systems failure the size and scale of Texas and to explain it all would require a book. This paper will look at the risks, opportunities, and drivers of Texas electric grid, what caused it to fail, and incentives to succeed in the future. We will also examine incentive systems gone wrong such as the Cobra Effect. [ABSTRACT FROM AUTHOR]

Logical or abstract architectures are an essential concept in systems engineering. They are included in the systems engineering handbook, the OOSEM process, the SEBOK, several modeling languages, and the ISO 15288 process definition. A logical architecture is a solution‐independent model of the problem domain used to understand "what" needs to be done, while avoiding defining "how" it will be done. The logical architecture includes all the related logical elements without constraining the architecture to a particular technology or environment. It traces to the physical architecture which defines how to implement the architecture using specific technologies. Logical architectures can be defined using MBSE languages such as the systems modeling language (SysML). They are implicit in the Operational set of views in architecture frameworks such as DoDAF, MODAF, NAF and their implementation in UAF using SysML. NAF has recently changed the title of the Operational views to Logical views to further emphasize the purpose of the views. This paper will define the benefits of using a logical architecture and provide guidance on how it can be implemented. [ABSTRACT FROM AUTHOR]

Using electricity to directly power moving vehicles has been used for a long time as evidenced by trains, trams, and electrical buses. Providing electricity to move heavy transport trucks on roads Therefore does not represent a huge innovation. Since heavy haulage traffic on roads represents a significant part of carbon dioxide emissions, electric roads (ERs) that can provide engine power to heavy road haulage is seen as significant by the Swedish government (Bateman et al, 2018SP04EN). Several Swedish government authorities as well as private companies are actively testing equipment both for trucks as well as roads. Once they have been deployed, ERs will also provide benefits as regards air quality and traffic noise. This paper describes a concept analysis project that uses models and simulation to analyze electric road scenarios. Electric road enabled trucks of different types run along an electric road and are subjected to different road conditions, speed restrictions as well as queues over a defined amount of time. The ability to analyze both management and energy consumption of an electric road is of paramount importance in determining its ability to accomplish the desired carbon‐dioxide emission reductions. [ABSTRACT FROM AUTHOR]

Services in the Unified Architecture Framework (UAF) are not just software services. Services can include transport, surveillance, communications, providing healthcare and medical services, etc. The UAF implements DoDAF using the Systems Modeling Language (SysML) as well as the British MODAF and NATO NAF. The DoDAF Service views implement services by duplicating the systems views and labeling the systems elements as services. This causes some confusion with engineers who either implement solution‐based service views or ignore them completely. Even when implemented, they can cause confusion in the model as it becomes difficult to tell if a model element describes a service or a system implementing a service. The UAF implementation of the MODAF services views provides a distinct set of views, concepts and traceability. The Service Oriented Views do not specify how the service is to be implemented, but the requirements for the services. The Resources (Systems) Views implement services in various phases and their deployment will modify the configurations of the system at the very highest level. This paper will show how services views trace from capabilities and how that can be used to define system resource requirements. [ABSTRACT FROM AUTHOR]

Architectures, systems, subsystems, and the data that they contain, are valuable assets. Systems engineers and architects must plan for system security from concept inception to retirement to ensure that security is embedded into every part of every process, procedure, system and component as well as in the mindset of the people in the enterprise. While the various DoDAF views contain attributes of security, there are no views for defining system security goals, threats, risks, mitigating elements, etc. and demonstrating how these are integrated and implemented into the operational, system, standards and services views. The Unified Architecture Framework (UAF) has integrated a set of security views that provide engineers a means of defining security goals and requirements and demonstrating how these are implemented throughout the architecture. [ABSTRACT FROM AUTHOR]

A Frenemy is "a person with whom one is friendly despite a fundamental dislike or rivalry." (OED, 2018). The Systems Modeling Language (SysML) and the Object Process Methodology (OPM) are two such frenemies. OPM and SysML are different means of achieving Model‐Based Systems Engineering (MBSE), each with their own benefits, issues, supporters and detractors. The National Defense Industry Association (NDIA) defines MBSE as "an approach to engineering that uses models as an integral part of the technical baseline that includes the requirements, analysis, design, implementation, and verification of a capability, system, and/or product throughout the acquisition life cycle." (NDIA, 2011) SysML is based on the Unified Modeling Language (UML) and includes diagrams that can be used to specify system requirements, behavior, structure and parametric relationships. SysML provides a means of defining high‐level abstract systems down to detailed physical systems. OPM is a "conceptual modeling language and methodology for capturing knowledge and designing systems. Based on a minimal universal ontology of stateful objects and processes that transform them, OPM can be used to formally specify the function, structure, and behavior of artificial and natural systems in a large variety of domains." (ISO, 2015) OPM is used in some systems engineering graduate courses. Students graduating from these institutions are struggling to integrate the differing styles, philosophies, concepts and processes of SysML and OPM. A literature search reveals some papers that contrast SysML and OPM, but none that describe how the two can work together. This paper discusses a synergy of SysML and OPM in a SysML tool rather than promoting one language over another. [ABSTRACT FROM AUTHOR]

A digital twin is much as it sounds: a digital representation of a specific asset in the field, including current and past configuration states, considering serialized parts, software versions, options, and variants. Condition data is also represented including sensor readings, alerts, and operating environments. A digital twin has significant implications for service, operations, analysis, design, etc. especially when visualized as a Computer Aided Design (CAD)‐sourced graphic in 3D virtual or augmented reality. Using this immersive and real‐time information, engineers can inspect and verify the asset being serviced, designed or operated to get precise product information. However, the digital twin does not spring into life fully formed straight from the CAD model. It requires an informed system engineering approach to ensure that the integration between physical and digital is fit for purpose. Model‐Based Systems Engineering (MBSE) models can be used in conjunction with the digital twin to improve operational models, predict and analyze faults, perform best‐fit analysis and eliminate inappropriate system configurations, etc. This paper will look at various aspects of the digital twin and how it can be used in conjunction with MBSE. [ABSTRACT FROM AUTHOR]

Abstract: Systems interoperate using interfaces. They exist between capabilities, organizations, people, systems, people and systems, systems and nature, systems of systems, and so forth. Interfaces are used to support both system to system communication as well as supporting the complete set of enterprise goals. Interfaces are where the most interesting things happen. And where most things go wrong. This paper addresses system interface‐management issues and the benefits of Model‐Based Systems Engineering (MBSE) approaches. An initial focus will be placed on interface information content that needs to be addressed at each level of system decomposition – from external stakeholders to system boundary to eventually, system component‐to‐component. The focus will then shift to interface management to model‐based and functional/logical design practice. It will also cover system interconnection and communications, how they change, operate and evolve over time to implement mission goals and to satisfy stakeholder needs. Finally it will look at physical systems and the connection to PLM/CAD domains. Defining stakeholder goals and required capabilities Interface definition with MBSE Functional Architecture Interfaces Logical Architecture Interfaces Physical Architecture Interfaces Allocation across cross cutting views How behavior drives interfaces which drive behavior Defining interaction requirements Implementing effective and testable interface specifications Traceability throughout the architecture Service Oriented Architectures. [ABSTRACT FROM AUTHOR]

Abstract: Model‐based systems engineering (MBSE) is the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases. The INCOSE Integrated Systems Engineering Vision 2025 [INCOSE, 2014] describes how future systems engineering tools will facilitate systems engineering practices as part of a fully integrated engineering environment. A shift towards an integrated, digital engineering environment enables rapid transformation of concepts and designs to digitalized virtual prototypes and then to physical prototypes through the application of additive manufacturing technologies, such as 3D printers and the digital twin in operations. This capability enables engineers to rapidly and continually assess and update their designs prior to committing costs to production hardware. Implementing this vision will require an integrated suite of tools, technologies, and standards to support the full systems engineering and product lifecycles from requirements to design to implementation and maintenance. MBSE models are digital and executable, and using an MBSE simulation engine, they can shift risk towards early stages of project development as the asset can be tested before it is built. In operations, IoT technologies enable companies to capture and leverage information about a product's performance during operation – with the potential to dramatically improve existing and future products. Service Lifecycle Management (SLM) solutions combine IoT platform technology with service solutions. This integrated closed loop systems engineering toolset applied to the Oil and Gas Industry will ensure success of the Digital Engineering Journey. This paper will describe this Digital Engineering Journey using a Coal Seam Gas example. [ABSTRACT FROM AUTHOR]

Abstract: Product Line Engineering (PLE) is the engineering and management of a group of related products using a shared set of assets and a means of design and manufacturing. PLE can include system and software, assets and involves all aspects of engineering including electrical, electronic, mechanical, chemical, etc. PLE is normally considered after the product has evolved and complexity becomes too much to manage. Leveraging PLE from the very beginning will identify cost savings and commonality and provide a natural means for product evolution. Orthogonal Variability Modeling (OVM) provides a natural decision set allowing engineers to perform trade‐offs for specific customers and guide system development along the most effective route. Using automotive examples, this paper will describe Model‐based Product Line Engineering, the process for creating product lines, and the benefits of this approach as applicable to the military ground vehicle domain. Finally, it will show how the adoption of MB‐PLE early on in the development lifecycle provides more benefits without the potential disruption and re‐engineering that can be involved when it is adopted later on in the lifecycle. [ABSTRACT FROM AUTHOR]

Abstract: The Internet of Things (IoT) is a system of systems (SoS) in every sense of the definition. A.P. Sage and others list five common SoS characteristics: operational independence of the individual systems, managerial independence, geographical distribution, emergent behavior and evolutionary development or independent life cycles. Typical examples include smart houses, the electric grid, complex military systems and so‐called smart cities. The future of IoT success, including technology advancements and revenue generating potential across the business spectrum, is dependent on the application of solid Systems Engineering and Model Based Systems Engineering (MBSE) principals. Without MBSE, the complexity involved in the design, development, and deployment of IoT systems would consume both system and operational providers. Absent of any industry standards, IoT systems cannot be built in a vacuum and their success will only be realized through application of modern day systems engineering processes, methods, and tools. With the potential of 28 billion “things” connected to the Internet by 2020, it's not too difficult for anyone paying attention to this emerging technology trend to envision the massive scale of social, economic, and technological changes that will need to occur to realize this prediction. Technology advancements in consumer products will continue to evolve to facilitate connection to larger and larger IoT networks. This will be the catalyst that will drive entire infrastructures changes to: Federal, State, City, and local governments; product development companies; utility and service providers; and even to consumers and their homes in order to support the growing demand for connected products. The infrastructure and management will need to be established prior to, or in conjunction with, the smart systems that support them. This paper will show a traffic management system and connected systems in a large city and how an MBSE and SoS approach will help guide development. [ABSTRACT FROM AUTHOR]

Abstract: Architecture frameworks continue to evolve. The Unified Profile for the Department of Defense (DoD) Architecture Framework (DoDAF) and the UK's Ministry of Defence Architecture Framework (MODAF) (UPDM) provides a standard means of representing DoDAF, MODAF, and NATO Architecture Framework (NAF) conformant architectures using the Unified Modeling Language (UML), and Systems Modeling Language (SysML). Since the UPDM V2.0 publication, further information has emerged such as the June 2011 NATO study entitled: “Development of The AMN (Afghanistan Mission Network) Architecture In 2010 – Lessons Learned,” by Torsten Graeber of the NATO C3 Agency. This report identified the following in section 4.1‐ARCHITECTURE FRAMEWORKS, sub‐section 4.1.2 Observations (Need for a Unified Architecture Framework) and stated that: • differences in DoDAF, MODAF, and NAF make it difficult to match the metamodel one to one. • some of the concepts in the frameworks have the same name but different definitions, i.e. different semantics. • difficult to cross‐walk the concepts between the different frameworks leads to miscommunication between architects using different frameworks. Based on the above, the NATO Architecture Capability Team (Architecture CaT) meeting on Sept. 10‐11, 2012 committed to move to a single world‐wide Architecture Framework. Consequently, a new architecture framework profile supporting a unified framework is needed. It is intended that this framework bring the different architecture frameworks together. The UPDM V3.0 domain metamodel shall be derived from MODEM (the MODAF metamodel) and the DoDAF 2.0 metamodel (DM2), both of which are based upon the International Defence Enterprise Architecture Specification Foundation [IDEAS]. This paper will document the rationale behind the UPDM 3.0 as well as its new name of the Unified Architecture Framework (UAF). [ABSTRACT FROM AUTHOR]

Abstract: Product Lines are a group of related products manufactured or produced within or between collaborating organizations. To effectively manage a product line, one needs to understand both the similarities and differences between the different products and optimize the development lifecycle to leverage the similarities, and concentrate development on the differences. ISO 26550:2013 Software & Systems Engineering – Reference Model for Product Line Management & Engineering provides a standard for defining these similarities and differences as well as the choices between them. Model‐Based Systems and Software Engineering (MBSE) using the Systems Modeling Language (SysML) and the Unified Modeling Language (UML) provide a means of modeling systems and software. Bringing the two together allows users to model product lines in industry standard formats. These standards provide Model‐Based Product Line Engineering (MB‐PLE). Combining these with an execution engine means that product models can be created for specific products, whilst maintaining the original product line model. This provides significant ROI for aerospace companies. [ABSTRACT FROM AUTHOR]

Abstract: Large infrastructure projects are complex, difficult and expensive. They are found in the transportation, energy, and communications sectors. These include projects for aerospace, and construction of public works and utilities, airports, sea ports, rail, highways and bridges, among others. They are subject to the requirements of a multitude of stakeholders, take many years to build, are often influenced by politics, and can lack focus or involve scope creep. They are also subject to laws and regulations, operational concepts, site conditions, external interfaces and utilities, industrial codes and standards, operator needs, the public interest and other influences. Projects often suffer several types of problems caused by inadequately determining, engineering and managing requirements. For example, contractual and regulatory commitments can be overlooked. Requirements do not flow down to subcontractors or suppliers. Requirements are incomplete, unclear and subject to widely varying interpretations. Projects have difficulty demonstrating requirements were met. Examples of projects where virtually all of these problems occurred include the Millennium Dome in the UK which was bankrupt shortly after opening (Projects, 2012), and the Freedom Tower (New World Trade Center) in New York City (Time, 2005). Solving these and other issues drive the need for more formal approach to managing these projects. There is a significant advantage to be gained by the adoption of systems engineering methods within the remainder of the infrastructure sectors. The INCOSE Infrastructure Working Group was formed to demonstrate how systems engineering can assist with infrastructure projects. As a part of that effort, we have created a drawbridge model to demonstrate how Model‐Based Systems Engineering (MBSE) can assist engineers in defining clear requirements, defining scope, demonstrating regulatory compliance, identifying stakeholders, etc. It uses the Unified Profile for DoDAF and MODAF (UPDM) and the Systems Modeling Language (SysML). This paper will describe the model and demonstrate how the different aspects of MBSE help infrastructure projects. The model contains close to 100 diagrams and reports, so size constraints of the paper mean that only selected parts of the model can be described. For the complete model, visit the IWG area of the INCOSE website. http://www.incose.org/practice/techactivities/wg/infrastructure/ [ABSTRACT FROM AUTHOR]

Reports on the extension of the Unified Modeling Language (UML) from software into the systems-engineering space. Use of SysML, a novel modeling language derived from UML, to model both hardware and software in the same environment; Development of a program aimed to provide a standard modeling language for systems engineering; Benefits of the existence of an underlying model on the capability of UML to support diagrams. INSETS: FLOW MOTION;MODEL EXCHANGE.

Discusses the use of use-case diagrams in computer programming. Applications of use-case diagrams; Reason behind the use of use-case diagrams by practitioners of extreme programming; Importance of defining the goals of the actor at the start of system development. INSETS: DIGESTING THE SPEC;EXTENDING RELATIONSHIPS;USE-CASE PITFALLS AND HOW TO AVOID THEM.

Focuses on the role of use-cases in building information necessary for an effective safety case in system development. Information on use-cases invented by Ivar Jacobsen; Potential hazards of using a system service in the context of safety-related systems; Use of a system mode diagram in use-cases; Need to develop a clear use-case strategy before its implementation and use.