Mastering increasing product complexity with Collaborative Systems Engineering and PLM

Transcription

1 Mastering increasing product complexity with Collaborative Systems Engineering and PLM Thierry Ambroisine Dassault Systèmes 10 rue Marcel Dassault, Vélizy Villacoublay, France Abstract: Companies are under pressure to manage the increasing complexity of globally developing innovative new products while meeting enhanced features needs, cost, quality, regulatory and time to market targets. Embedded software, electronics, mechanical and test engineering have all independently adopted a model based design approach. While the resulting benefit to each discipline has been impressive, the number of different tools used in developing these products continues to grow dramatically, resulting in a multidisciplinary heterogeneous and fragmented tool environment and engineering silos. Product Lifecycle Management (PLM) systems, initially targeted at engineering business process and data management, have evolved to address these Systems Engineering challenges. They provide a collaborative multi-disciplinary platform that enables the orchestration of product development facilitating cross-domain requirement and test management, system architecting, change and configuration management. This presentation will outline the challenges of integrating product lifecycle management and heterogeneous engineering platforms and how it is transforming the business processes, modeling and tools frameworks. Keywords: Product Lifecycle Management (PLM), Complexity, Systems Engineering, RFLP, Embedded Systems, Model Based Design, Requirement Engineering, System Architecting, Change Management. Embedded World Conference 2013

2 Introduction The increasing complexity of products, competition, and innovation pressure driven by customer needs are challenging organizations to shift from a product development process to a Systems Engineering process. Traditionally, the product development process is led by an engineering discipline (i.e. electronics or mechanical), involved in addressing in priority the increasing complexity for its particular domain and further integrate the other disciplines contributions (i.e. electrical, software) with a late harmonization between all the disciplines, sometimes at the physical prototype integration process stage. Moreover, system services delivered to the user are more and more implemented by the cooperation between multiple embedded systems solutions issued from contributions of several engineering disciplines. Therefore, late harmonization between disciplines using these technologies reduces even more the possibilities of success. The complexity of a system is mainly linked to its composition of heterogeneous elements, including mechanical, electrical, electronics, software and others, the interrelations of its elements and the dynamics of these interrelations. The systemic approach is a good approach to manage complex problems. A complex system not being able to be analyzed in details, it is studied as a whole. Systems Engineering has to integrate multiple view points in a global, holistic view, distinguish problem domain from solution domain, separate elements, interactions among the elements and analyze how combined elements behave.systems Engineering Process Overview The Systems Engineering process enables to transform the needs and expectations of customers and stakeholders into a product solution which provide the expected services in order to achieve the customer satisfaction in the most cost-effective way considering performance, cost, schedule and risks. The art of engineering complex systems is to find the right level of abstraction between customer needs and system elements to be detailed by engineering disciplines. The Systems Engineering process starts with the capture of voice of the customer and its derivation in system technical requirements based on the analysis of the use case scenarios of the system. The identified functions are then allocated to solution architecture defined by subsystems, components and their interrelations. The system functions and logical components behavior are also defined and simulated to ensure that requirements are met. Embedded World Conference

3 Systems Engineering Tools platform The Systems Engineering platform must enable product development actors (Customer, Stakeholders, Product and Project Managers, System Architects, Engineers) to formalize, share and control a single source of the system definition. It must allow to formalize customer needs,technical requirements and perform global product traceability across the product definition. Systems architects must be able to model and validate the global system behavior enabling global system optimization, concept dimensioning and multi-discipline interface management providing early product validation. A Systems Engineering tools platform must therefore provide a whole system abstraction and interdisciplinary process approach to federate engineering disciplines and specialty groups with a structured end to-end development process that proceeds from concept to disposal. This platform must provide a system level data model to ensure a unified cross discipline system definition and virtual product modeling and simulation. As a result, technical solutions can be evaluated taking into account the behavior of components and the interacting environment. If we have a better understanding of the Systems Engineering platform objectives and benefits on the process and data model perspectives, we have to consider that a successful multidisciplinary collaboration at system level can only be achieved by a common understanding of the system definition. We introduce the RFLP (Requirement, Functional, Logical, Physical) paradigm for this objective. RFLP paradigm enables to define a system based on its fundamentals aspects or facets through essential views and their relations: - The Requirements and Tests View - The Functional View - The Logical View or architecture View - The Physical View The Requirement and Tests View (R) defines customer and stakeholders needs and as the results of their derivations in technical terms: what characteristics, activities the system shall satisfy. The test defines the requirement verification protocol, the acceptance criteria, and the results. The Functional View (F) defines what the system does, what actions or activities that must be accomplished to achieve a desired outcome, or to provide desired capabilities. This view formalizes the understanding of the intended use of the system (operational functions, use case scenarios, services) and its decomposition into elementary functions that can be allocated to technical solutions. The Logical View (L), or logical/organic architecture defines how the system is implemented The Logical View defined the technical solution based on subsystems, components and their interrelations according to customer needs, technical requirements, and expected functions. The Physical View (P) defines a virtual definition of the real world product, including 3D representation to visualize the targeted system concept in the early phases. Embedded World Conference

4 The Functional and Logical Views include behavior models to define how functions or logical components transform inputs into outputs, react to events, or respond to excitations. Behavior models can be distinguished with events (discrete) and/or physics (continuous) domains, based on event modeling languages (e.g. state chart, state/transition) and dynamic modeling languages (e.g. Modelica) for mechanical, hydraulics, electrical, real time, etc. Functional and Logical Behaviors enable to virtually Experience the system and predict its characteristics in order to validate decisions and verify that requirements are met before significant resources are engaged to its detailed design, development, validation and operation. Relations between RFLP views can be defined with links describing that an element is implemented by/ allocated to/ satisfied by another one. For example a Requirement can be linked to a Logical Component: it means that the Logical Component satisfies this requirement. RFLP links provide a fully traceability from Initial Customer Needs to Physical Design in both directions enabling a right to market delivery. Situation Embedded software, electronics, mechanical and test engineering have all independently adopted a Model Based Design approach, implementing somehow a RFLP paradigm with their own disciplines representations and terminologies. With increasing complexity of electronics designs and the increasing software part, a system level approach has emerged for Electronics Engineering: Electronic System Level design (ESL), with VHDL-AMS, SystemC languages for example. Software Engineering has also extended their modeling languages with UML foundations, SysML for example. Control Engineering, System Level design for control systems relies on hybrid discrete/continuous physics behavior modeling platforms with a component based approach and component libraries, using the Modelica language, for example. Electrical & Electronics Engineering for automotive industry relies on dedicated platforms with the capability to model vehicle E/E architectures based on ECU, buses and networks. Mechanical Engineering and CAD detailed design has evolved to master the complexity of the integration of electronics devices in Mechatronics Systems. Product Lifecycle Management (PLM) and its collaborative systems engineering platform has emerged with RFLP paradigm to master the collaborative multi-discipline systems engineering Embedded World Conference

5 process, dynamic modeling, simulation (based on Modelica for ex.), system level product virtualization that helps systems architects to control the complexity, while meeting customer requirements and improving product performance. Moreover PLM platforms ensure the product management (Bill of Materials), portfolio and diversity management, change management at product level, in coherency with programs and projects. This situation reveals the need for the integration of a heterogeneous and fragmented tool environment and reaches a successful management of the complexity based on a systems engineering approach based on the cooperation of the engineering disciplines at system level. Business Process Transformation Challenge The RFLP Paradigm and its affordable facets/views for all engineering disciplines is a key structuring enabler for this business process transformation challenge. By sharing the system definition with a higher abstraction level of representations and semantics, RFLP acts as a catalyst for multidisciplinary systems composition between the system level and engineering discipline level. RFLP business transformation with top down and bottom up approaches enables to define system concepts earlier in the lifecycle, evaluate multiple alternatives, Experience their behavior and accelerate the innovation for a competitive advantage. Moreover, the ability to define reusable RFLP system definitions allows the productivity to be enhanced and a better management of the diversity of a product portfolio with product variants. The business transformation for engineering disciplines implies that they must be able to handle a RFLP subsystem, components, cooperate and negotiate on functional and logical interfaces and behaviors. They must be able also to provide, publish RFLP answers to an upper level RFLP system definition. Finally, for the initialization of their detailed design, engineering disciplines should be able to at least ensure the traceability to RFLP system definition, and ideally transform it in their discipline specific models. For the integration of their detailed design, engineering disciplines should be able to at least attach it to the RFLP, and ideally transform their own discipline models in a RFLP system definition with the right abstraction level. RFLP business transformation beyond engineering disciplines, should be applicable for OEM/suppliers collaboration, supporting make/buy analysis and acquisition processes (request for proposal). Modeling Frameworks transformations The RFLP paradigm provides the referential, or modeling framework for multidisciplinary cooperation at system level. RFLP structures the system definition semantics and defines the role of each representation or model of the framework. The system modeling framework must be adapted by the company based on their systems engineering know-how. The RFLP modeling framework can be approached as follows : The Requirement and Tests View (R) defines needs and requirements - requirements: requirement statement, in some case requirement are directly defined with models not related to functional or logical views at this stage - tests : test definition (Test management, Simulation Lifecycle Management) Embedded World Conference

6 The Functional View (F) defines what the system does - Operational (Intended use) - structure: functional breakdown structure, context diagram, onion model, use case scenario, - behavior: sequence diagram, state/transition model (operational modes) - Functional (Internal/Technical) - structure: functional flow diagram, functional interfaces, flows - behavior: state/transition model (functional states), physics (environment behavior for functional analysis).the Logical View (L), or logical/organic architecture defines how the system is implemented, - structure: breakdown structure, block diagram, logical interfaces, logical connections, logical 3D (space reservation) - behavior: discrete behaviors, physics behaviors, hybrid behavior The Physical View (P) defines a virtual definition of the real world product - structure : 3D model Tools Framework transformation The tools platform transformation areas can be identified on a process view with the related tools. The systems engineering process can be structured for our objective as follows: Technical processes - Requirement Engineering - Functional Analysis - Logical Architecture Design - Systems Modeling and simulation - Physical Architecture Definition - Integration - Verification & Validation Management processes (Governance) - Requirement Engineering (Management) - Configuration & Lifecycle management - Change Management - Issue & Defect Management - Portfolio Management - Multidiscipline collaboration PLM tools platforms ensure the Management processes with a governance approach of the data. Technical processes are managed with a work in progress approach and dedicated data models. Embedded World Conference

7 Requirement Engineering and Traceability Requirement based engineering processes means capturing requirements from numerous file and database sources (Windows/Office, Doors, ALMs, ReqIF, ) in a wide variety of data and file formats and link them (with easy to implement traceability links) to development and verification artifacts, through the provision of a large number of interfaces to common systems engineering tools. These traceability links should not only operate at file level, but truly at fine-grained engineering artifact level, enabling effective requirement coverage and change impact analysis Functional Analysis and System Architecture Functional Analysis and System Architecture identify the functions the system shall accomplish and the system, subsystems and components. The integration with PLM tools platform implies at least to ensure the traceability with engineering data, supported by the link with the PLM model or its storage as document. This integration shall offer the capability to open the data from the PLM platform. An extended integration should enable model transformation between engineering data and PLM systems models. Behavior Modeling and Simulation The integration with the PLM platform shall be considered for the model definition on one side and the execution of this model on the other side, for local or larger simulations including other behavior models. The integration principle for the definition can be the same as for the functional and logical models: link with the PLM model or its storage as document and capability to open the data from the PLM platform. An extended integration should enable model transformation between engineering behavior models and PLM systems behavior models The integration with the PLM platform for the execution of behavior models shall be managed with an open simulation standard. Functional Mockup Interface (FMI) has been defined for this objective. Management The integration with the PLM platform for management processes implies to ensure the collaboration of the PLM platform with the disciplines engineering data management platform: - Electronics Data Management Embedded World Conference

8 - Software Change & Configuration Management - Legacy data management software The tools framework transformation gives to the PLM platform the role of Engineering Hub for all the engineering disciplines. Conclusion The increasing complexity of product development with more and more smarter products drives the need for an integrated systems engineering process to ensure a true multidisciplinary collaboration at system level in a heterogeneous and fragmented tools platform environment. The business process transformation in this context implies to define a common understanding of the system definition and engineering. The RFLP (Requirement, Functional, Logical, and Physical) paradigm should be an enabler with its affordable essential facets for all product development actors including the customer itself. The tool framework transformation drives for a PLM platform acting as an Engineering Hub with discipline engineering tools, and ensuring a unique source of definition, global product and process management, traceability, model transformation and virtual product experience. This business process transformation, modeling and tools framework transformation, contribute to engineering excellence, innovation acceleration and productivity enhancement based on product and portfolio management associated with reusable multidisciplinary system RFLP assets. Embedded World Conference