Insight最新文献

This paper presents combining MBSE (Model-Based System Engineering) and STPA (Systems-Theoretic Process Analysis) to mitigate security risks at an early stage of system development and to increase agility when developing or modifying architectures. The MBSE approach states that the systems development process should have a system model or a set of models as the unique source of truth. From the system model or a set of models, systems engineers of different specialties should be able to extract the information needed to perform their job. However, some specialties usually create their artefact apart from the model to perform the analysis, breaking the premises of MBSE to have a unique source of truth leading to out-of-date artefacts. This article proposes extending the Unified Architecture Framework (UAF) Profile (UAFP) to enable safety and security systems engineers to perform their analysis from the early stage of a system development process.

Model-based systems engineering (MBSE) with agility can help systems engineering programs which deal with both increasing complexity and frequent changes in environment and usages, shorter time-to-market, uncertainty of the needs, and more sophisticated industrial schemes. Agile approaches originated in software engineering can be extended and tailored to a certain extent to complex systems engineering and particularly to MBSE. Main benefits of agility are provision of a minimum viable product as early as possible in the schedule, early capture of changes of needs, enabling to deliver a system answering to the real needs, and securing of the value proposal. It includes also potential reduction in rework of the final system through regular customer feedback throughout development (left shift for the defect correction with early exposure), and efficiency of the use of resources. Concerning MBSE, the use of models as a single source of truth for completeness and consistency is useful to share and secure the design by improving communication within engineering teams and the building and support of the development strategy, and to help to automate some tasks such as model exchange and synchronization. In addition to the benefits of each approach, combining them may help to:

• ▪ Organize and synchronize the development and validation effort of one or multiple engineering teams.
• ▪ Faster impact analysis including trade-off studies/options and hence a faster reaction to evolutions in expectations and constraints, that is, the agility of systems.
• ▪ Show regularly “end to end” value to the customer and other stakeholders.

Loss-driven systems engineering activities are key to realizing successful systems. At the same time, loss-driven systems engineering assessments are, in most cases, complex. In real life projects, integrating loss-driven systems engineering activities in the system development activities might be difficult. In some cases, there is a lack of understanding the activities' importance and sometimes there are organizational barriers. To overcome those barriers, we propose an approach based on widely accepted standards. The difficulty is most existing systems engineering standards poorly describe loss-driven systems engineering activities and how they integrate with traditional engineering activities. This paper provides an approach to successfully accomplish this integration. It is extremely important to involve loss-driven systems engineers in every life cycle phase. At the same time, achieving a common integrated approach understanding is necessary.

Modern engineered systems demand lifecycle strategies that are responsive, risk-aware, and aligned with evolving needs. Historically, systems engineering has been methodology-driven, with formal frameworks such as the V-Model or waterfall used to guide process rigor and governance. These methodologies provided structure and control, especially for large, safety-critical engineered programs. However, as systems have become more complex and adaptive, the limitations of rigid methodological adherence have become increasingly apparent. This article retraces the reasoning behind moving from methodology-driven to function-driven, to outcomes-focused, and finally to functionally enabled outcomes. It introduces the concept of functional-outcomes driven tailoring (FODT) as a unifying framework that drives lifecycle performance through functional alignment to mission outcomes.

This article discusses the role of a “specialist” Systems Engineer inside an engineering focused on ensures the engineering parts integrate to achieve the objectives of the whole – and so is embedding a systems approach throughout the organization – trying to “make Systems Engineering the way engineering is done”. In this type of organization all engineers need systems engineering as a core skill (which is part of them becoming T-shaped“. The specialist Systems Engineer needs to be more π-shaped, with specialism in the systems approach used to inform and guide all the other disciplines which need to be integrated together. Since systems engineering is an integrating discipline the group of systems engineers must not become ”just another“ technical silo.

The high-tech equipment industry brings complex industrial products to the market with high speed, enhanced functionality, a better cost-performance ratio, and greater integration into customer workflows. Driven by digitalization, the complexity of these systems continues to grow steeply. To manage this complexity, continuous innovation in systems engineering methodologies is needed. TNO-ESI targets to 1) create impactful and industrially applicable systems engineering methodologies and 2) provide innovation support to the industry to get these applied in an industrial context. The ESI research program is defined through a roadmapping process that follows two tracks: a roadmap that maps industry needs and related research and development requirements and a roadmap that describes the developments in the expertise areas necessary for addressing these industry needs. In this paper, we describe the ESI mission, our way of working and activities, and explain the roadmapping process and the roadmaps.

Automotive software is undergoing a rapid change toward artificial intelligence and towards more and more connectedness with other systems. For both, an incremental design paradigm is desired, where the car's software is frequently updated after production but still can guarantee the highest automotive safety standards. We present a design flow and tool framework enabling a DevOps paradigm for automotive software development. DevOps means that software is developed in a continuous loop of development, deployment, usage in the field, collection of runtime data and feedback to the developers for the next design iteration. The software developers get support in defining, developing, and verifying new software functions based on the data gathered in the field by the previous software generation. The software developers can define contracts describing the time and resource assumptions on the integration environment and guarantees for other dependent software components in the system. These contracts allow a composition of software components and proof obligations to be discharged at design time through virtual integration testing and runtime through continuous monitoring of assumptions and guarantees on the software component's interfaces. An update package, consisting of the software component and its contracts, is then automatically created, transferred over the air, and deployed in the car. Monitors derived from the contracts allow for supervising the system's behavior, detecting failures at runtime, and annotating the situation to be included in a data collection, fueling the next design iteration.

The significant shift happening today towards more connected, more automated, and more autonomous systems is bringing software inside all systems, and at the same time agile practices. Our experience of large-scale agile deployments in companies building or operating complex systems in automotive and aerospace shows that, whereas both approaches can easily coexist in isolated teams within the same company, major problems arise when coordinating them at the leadership level, where they are perceived as antagonist, and create misalignments, friction and quality issues. In this article, we propose to describe why it is important to make agile and systems engineering work together, how to do it, and how this impacts how we see value, systems, digital twins, and leadership. The following concepts of the FuSE agile roadmaps are addressed:

• ▪ Agility with long lead time components and dependencies
• ▪ Agility across organizations boundaries
• ▪ Orchestrating agile operations.

This article addresses the inherent risk in a supply chain that comprises primarily Very Small Entities (VSE) with little to no security proficiency and limited resources and incentive to prioritize system security. In a globalized economy based on outsourcing and risk-sharing, most engineering activities occur in the smallest companies, even for large and complex projects. The Future of Systems Engineering initiative (FuSE) appropriately has agility at the core of its Systems Security Engineering (SSE) foundation concepts, and VSEs are by their very nature agile. However, the line between agility and chaos may be thin, and engineers at VSEs must often accept a level of restraint and rigidity beyond their comfort level to achieve functional agility. The primary challenge in VSEs is adding structure without the necessary resources to enforce compliance manually. We propose that VSE focus their initial efforts on FuSE SSE Foundation Concepts that play into their nature and strengths as dynamic human social activity systems. Improvements in security proficiency and stakeholder alignment do not necessarily require much formal structure, and digital tools combined with social strategies can add structure to a resource-constrained environment. Games can be excellent low-cost tools to provide structure while minimizing resistance, and Agile Model-Based Systems Engineering (AMBSE) using digital models can support automated enforcement. Here we use the card game Elevation of Privilege (EoP) as an example. Within the context of a SysML Threat Model integrated into a larger System Model, players naturally treat security requirements as traceable functional requirements. Automated model validation, re-usable components and patterns enforce a Zero-Trust architecture, a sufficiently formal trust model to provide evidence-based assurance, yet achievable for small companies with limited resources.

Competency, the ability to do things, is at the heart of how systems engineers realise successful systems. Over the years INCOSE and partners have codified what this means, initially in the INCOSE UK Competency Framework (INCOSE UK 2010) later adopted globally by INCOSE and used as the basis of the INCOSE Systems Engineering Competency Framework (INCOSE 2018) which, notably, included a new area of professional skills. This article considers competency from the perspective of Diversity, Equity, and Inclusion (referred to as DEI) using a variety of sources including the recently published INCOSE SE Vision 2035 (INCOSE 2022) and a variety of competency frameworks to offer a view of how the skills and competencies of systems engineers need to evolve in the future. Five new competencies are proposed, as are opportunities to improve the definitions of five more.