strategic systems - eds technologies

STRATEGIC SYSTEMSEngineering for Functional and Logical Structures

http://www.3ds.com

© 2012 Dassault SystèmesTake Control: Intellectual Property Whitepaper

Contents

3 Abstract

3 Introduction

4 Evidence of Systems Engineering

4 Increasing Value of Systems Engineering

6 The Current Framework: Requirements and Parts

8 The New Framework: Requirement, Functional, Logical and Physical (RFLP)

10 Functional and Logical Overview

11 Establishing Value at the Highest Levels of System Structure

14 Summary/Conclusions

15 References

© 2012 Dassault Systèmes Strategic Systems Engineering for Functional and Logical Structures3

IntroductionSystems engineering is not a new discipline for today’s automotive OEMs and suppliers. So, why is it that many feel the discipline is under-utilized or not utilized at all in main-stream development? For those that do indicate systems engineering as a key activity in the development cycle, why is it common to disagree on a definition of what it is or how it manifests itself in the development cycle?

If one examines the development activity in today’s leading OEM’s and suppliers, there can be no doubt that product development in automotive is a complex and intensive activity. Many disciplines are utilized with many specialized skills deployed throughout the lifecycle of the typical automotive product. One can point to several tools that seem to indicate the presence of systems engineering, yet the ability to clearly define whether or not, or to what degree we leverage systems engineering, is still difficult.

AbstractMechatronics development continues to be a challenge for automotive OEMs and suppliers. Multi-disciplinary collaboration and development is critical, especially as architectures and solutions evolve in the automotive industry to satisfy changing needs of the customer and environment. New approaches to mobility, sustainment, and infotainment create the need for new combinations of electrical, software, mechanical, and chemical know-how.

Whereas most frameworks for requirements-driven model-based design support a single discipline, what is really needed is a framework for requirements-driven model- based design that can capture the multi-disciplinary architecture of the vehicle or system. This would and allow development organizations to then further decompose the objects in support of further refinement and validation. This means that the Requirement, Functional, Logical, and Physical (RFLP) approach must be applicable at the highest level of vehicle architectural development as well as the lowest level of technical decomposition.

Our approach on the topic of “Vehicle Architecture” is to show how RFLP can be used to define and refine vehicle definition and concepts even when the requirements may be somewhat “high-level.” With RFLP, vehicle architects can capture the “voice of the customer requirements” and use them to frame decisions at the highest level of the product definition, providing needed context for lower level decisions and analysis.

© 2012 Dassault SystèmesStrategic Systems Engineering for Functional and Logical Structures 4

Organizational Amnesia Stifles InnovationSimilarly, other departments would highlight how systems engineering can be demonstrated by detailed modeling and CAE analysis. Surely the virtual intelligence built into these complex models proves that systems engineering is present in the development process. Models created for simulating mechanical structures, for analyzing the behavior of electro-mechanical systems, and refining software control systems are shown. Again, the complexity of the structure, the organization of the modeled elements would be highlighted as evidence of higher-level systems thinking.

So what can we say defines the process of systems engineering in the automotive industry? The answer is that ‘all of the above ‘ activities and solutions, plus many more, make up the domain of systems engineering. In fact, systems engineering really isn’t a domain at all, it is the collection of all domains of engineering and development. In an even broader context, systems engineering is viewed from a point that includes more than just development activities. It can, and often should, include social, economic, and logistical functions in addition to the traditional development activities.

It is the viewpoint that extends systems engineering beyond a single domain or activity that enables the industry to better leverage the benefits of the discipline in the development of better vehicle technology, launched on-time and within enterprise objectives. In doing so, firms must look at systems engineering not as a tool or solution, but as the core process for delivery products. It becomes the very center of all development activity, providing the framework from which the automotive community develops product and technology. In subsequent sections of this paper we examine how we can position systems engineering as a development framework, through the addition of formal functional and logical structures inserted between the traditional requirements and physical structures.

Evidence of Systems EngineeringFirst, it is helpful to understand how systems engineering is utilized and where it can be found in the current automotive development practice. If asked for a description of systems engineering, many automotive managers would start with a detailed description of the requirements management activity at the front end of the development activity. There would likely be a detailed discussion regarding the structure and content of the requirements that are used to direct the detailed development teams. Key points would be made to show how many different types of requirements are managed within the process, including items like functional, non-functional, environmental, manufacturing, and service requirements. This might be followed by deep discussions about the complexity of the requirements structure. That is, engineers would proudly highlight requirements that are decomposed many levels from high-level targets, to detailed component specifications. They may even highlight that some requirements are “system requirements,” some are “sub-system requirements,” and others are “component requirements.” This discussion is very convincing and we might stop at this point, satisfied that we have found it.

However, if we go to another department, we might get a different proof point. Some of the portfolio managers might contend that systems engineering is present in the company, proven by the existence of a detailed description of features that are implemented by the product. They would point out an equally impressive list and, in many cases, structure of how the features of the vehicle are categorized, cataloged, and described. At the highest level of the structure, features are described in relatively ambiguous terms that match the marketing view of the product. Much like the requirements discussion above, the lowest level of the feature structure would contain very detailed descriptions of exactly how the feature would be implemented.


Increasing Value of Systems EngineeringSystems engineering is certainly not new in the automotive industry. Most leading automotive companies have formalized the discipline in one form or another into their development process. However, many companies voice a frustration over whether or not they are truly leveraging systems engineering for the benefits that are touted by proponents of the process. Specifically, in a study funded by INCOSE regarding the value of systems engineering effort (SEE), they found that increasing SEE resulted in a reduction in cost overrun, as well as a reduction in variability of project execution1.

So this begs the question, what is it that we can do to improve our systems engineering effort (SEE)? Let’s start with the definition of systems engineering. There are three commonly cited definitions of systems engineering referenced below:

“Systems engineering is a discipline that concentrates on the design and application of the whole (system) as distinct from its parts. It involves looking at a problem in its entirety, taking into account all the facets and all the variables and relating the social to the technical aspect.2”

“Systems engineering is an iterative process of top-down synthesis, development, and operation of a real-world system that satisfies, in a near optimal manner, the full range of requirements for the system.3”

“Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems.4”

Common elements of the above definition include the viewpoint that the discipline involves a broad viewpoint, which is multidisciplinary. In addition, the definitions point to the progressive problem solving and/or satisfaction of requirements as realized by some system that has been developed. However, none of the definitions seem to indicate specific tools and processes that are used. Conversely, they seem to indicate that systems engineering is the approach and the process for the development of a desired product. The INCOSE Systems Engineering Handbook1 goes on to describe many tools and processes that are used in the development of products using a systems engineering methodology. These include some of the following:

● Decision Management ● Requirements Management ● Risk and Opportunity Management ● Acquisition and Supply ● Architectural Design ● Project Management ● Quality Management ● Validation ● Verification ● Modeling, Simulation, and Prototyping

As can be seen, there are many processes and these processes are very broad in nature. Again, highlighting that systems engineering is more than just a tool or solution, it is a process and framework in the development cycle.

The contention of this paper is that the use of these types of tools and processes -- in part or in whole --, don’t indicate effective systems engineering or an increase in the systems engineering effort (SEE) as described in subsequent sections. The framework that is formalized in the development process provides the foundation to effectively employ the tools listed above in support of a systems engineering process for developing and delivering products. Since the systems engineering process can be present in many levels of decomposition of a product, we will focus our efforts on highlighting how effective a system engineering framework can


be in understanding the higher level architectural development in the automotive industry. This is fitting as we will be positioning the importance of establishing a framework for the understanding and decomposition of the product that should be present at all levels of decomposition. By nature, the decomposition activity prescribes a higher-level composition view of the product. So, how is this high-level view constructed, and can we gain real benefits from the view?

The Current Framework: Requirements and PartsThe current structure that is used for systems engineering in the automotive industry includes only two main structures; requirements and parts. Many will argue that other objects and representations exist, but these representations are typically transformations of the physical part structure or the requirements structure.

Figure 1: Path from Requirements to Parts Illustration

They are purpose built not to look at or understand the product in a different way; they are built to better format or fit the tool or process that is consuming the product information. Even if there is a significant transformation in the structure, or view of the product, this view is not valued independent of the tool that the structure is used for.

For instance, the transformation of an engineering bill-of-materials to a manufacturing bill-of-materials is typically a re-organization of the parts of a product to better reflect the manufacturing and/or sourcing process. The view is a necessary transformation of the part structure, but is typically not maintained as a core structure for understanding, architecting, and improving the system. In addition, the formation of a CAE structure for the purpose of analysis (the mesh product) is a modified representation of the physical part to allow for easier consumption of the data by the CAE tool being used. Many of these transformations exist, but they do not fundamentally change the way a product is viewed or understood.


Due to this gap, and the need for other tools that allow product development to engineer the product before coming to the physical product design, we focus systems engineering practices on simply relating requirements and parts to the structures and tools in between. We focus on questions regarding when to automate the integration and when to leave it to manual transformation. However, we don’t focus on the fundamental understanding of these relationships/integrations, they are just a means to an end, a way to use the tool and trace back to requirements.

For this reason, we typically use the requirements and physical part structure as the main framework with which to understand the product, connecting the needs of the customer, with the outcome of the development process. The lack of a common framework between the requirements and part structures represents a gap in progressing our understanding of “why” (requirements) we are developing the product, and the transformation to the parts we are developing to fulfill the requirements. We miss some fundamental questions about the products that we are developing. Specifically, “what” are we developing, and “how’ are we going to achieve our goals.


These views are not new, and these are terms that we typically use to define products when we are in the conceptual stages of development. However, these terms are typically not “formal” views of the product in the development process. Those that contend these structures are “formally” used, typically fall into two categories. The first category involves trying to fit functional and logical definition as a different subtype of requirement. These are handled and structured just like requirements, confusing the user as to what they represent, and typically losing the independence of the functional and logical views from the requirements.

The second category is to create them as different structures, but structures that are purpose-built for the individual tools that we use to model and develop before finalizing the physical design. These tools are represented as solutions in between the requirements and physical structures. The downfall with this approach is the lack of consistency in how we define the structures and the loss of value in the structure outside of the specific tool for which it is used. The functional and logical definition may be present in some fashion, but since the activity is meant to serve the purpose of some point solution, the focus and benefits of better understanding the product are lost. In the following citation Maier and Rechin5 describe the importance and principles behind some different viewpoints that are used for understanding a product.

The New Framework: Requirement, Functional, Logical and Physical (RFLP)If we are to better understand the decomposition and critical questions of “what” and “how,” then we must increase our scope of the development framework beyond requirements structures and part structures. We must include a framework that is suited to answer these questions, and it must be fundamentally and independently valued as part of the development process.

Inserting two structures to answer these questions can significantly increase our understanding of the development process and product. The structures inserted between requirements (R) and physical (P) part structures include the functional (F) and logical (L) structures. The functional objects and relationships help us to understand “what” we are developing, and the logical structure helps us define “how” we are going to accomplish our goals. The combination of these new structures transforms the traditional view to the requirement, functional, logical, and physical structure view, or simply RFLP.

These structures are created to help us understand fundamentally different aspects of our designs. As such, the structures are independent of each other in terms of structure. Requirement structures provide context as to why we are developing product, capturing the context of the customer needs and enterprise objectives. Functional objects and relationships provide insight in terms of what we are going to accomplish with the solution, providing development with a view of what the end product will do to accomplish these goals. The logical structures define how we accomplish these functions, potentially capturing different approaches to the problem that can be studied and compared. Finally, the physical parts represent the virtual product that will be manufactured or purchased and made available to the end-user.


“ The central idea behind Incium cor magnia que prem et est, occabor abo. Adicia porest iderspe vellest iatectes sam, consera temporrum cus iur suscium exerio. Itasitatur, eiundit ut verume res excepta volupta spedio eum laut fugitate eiciuribus dellabo.…”

Dr. Arthur LeBrasseur, Adjunct Professor, Tommy Johnson School of Business, University of California at Camarillo1

As indicated in the citation above, this approach involves specific structures and representations that allow the system architect to “view” the solution from different perspectives, with each view being most independent. In fact, the table referenced indicates some the views that are generally accepted as “most important.” It can be seen that understanding behavioral, purpose, and performance objectives are critical elements of understanding and architecting complex systems. The Dassault Systèmes RFLP approach follows the same principles of better developing and understanding complex products.

“A good set of views should be complete (cover all concerns of the architect’s stakeholders) and mostly independent (capture different pieces of information). Table 8.1 lists the set of views chosen here as most important to architecting.”

Table 8.1: Major System or Architectural Views

Perspective or view DescriptionPurpose/objective What the client wantsForm What the system isBehavioral or functional What the system doesPerformance objectives or requirements

How effectively the system does it

Data The information retained in the system and its interrelationships

Managerial The process by which the system is constructed and managed


provides information including inputs and outputs required, and thus provides a good definition for the software model that represents that piece of code. Additionally, a string of functions can be created and allocated to the logical object. This functional structure provides the definition to the developer for what the code will accomplish.

The tools used to model the behavior of the software can involve DS Dynamic Behavior Modeling, or the user may wish to use another solution. Either way, the user benefits from a formal structure that represents what the system needs to accomplish, and how it will be structured to achieve the goals. Now, multiple tools can leverage a common set of structures. Notice that the arrows are going in both directions from the point solutions to the RFLP framework. This is meant

to indicate knowledge and results from the solutions flowing back into the framework as addition context and knowledge for decision-making and architecture. This common framework better allows for lessons learned and knowledge to be managed centrally, rather than hidden in the individual solutions.

Functional and Logical OverviewUp to now we have established a need for the functional and logical views in between the requirements and physical product definition. This section provides additional detail as to how these functional structures are used. As indicated previously, the traditional approach is to directly link requirements to physical representations, with much integration in between. The RFLP approach provides a structured bridge that allows us to better transform requirements to physical form. These functional and logical structures provide additional views to leverage when employing tools like modeling and simulation to complex systems. Therefore our diagram from Figure 1 starts to look like the diagram in Figure 2.

In this figure the point solutions are leveraging a common framework and set of structures that include functional and logical definitions. For instance, logical structures can be created which represent software objects. These logical structures help to define how blocks of code will be developed and implemented on a given electronic control unit (ECU). The logical object

Figure 2: RFLP Framework Illustration


Conversely, the lowest level of detail might involve the specific software that is used to implement a network driver. The requirements at this level might involve minimum latency of certain messages being conveyed on the network bus. The functional representation will involve the encoding of software signals to approved messages. Logical objects could represent the network driver being coded to accomplish the function, and the physical structure could be the binaries or source code that implements this logical object.

It is clear that granularity is widely varied in the automobile from the top to the bottom decomposition. The value at the lower levels of decomposition is widely understood, especially in certain domains like powertrain and electrical/electronic systems. Examining the higher level structures are often overlooked because the structures seem much less definite or “fuzzy” in nature. However, understanding the high level composition of the product can provide some large benefits in terms of understanding and managing the proper focus, capturing knowledge, leveraging platform reuse, and achieving execution consistency.

First, managing the proper focus is achieved by establishing a direct link up the system-V to the ultimate goals of the product. As we add layers and layers to product requirements, we disconnect ourselves from the original context of the product intent. We lose the ability to make proper trade-off decisions, because we have lost connection to the customer needs. We assume we understand what the customer wants because we are meeting detailed requirements. However, design decisions can be made at the lowest levels that might cause us to re-evaluate decisions made at upper levels. Having a solid understanding of the high level product composition (requirements, functional, logical, and physical) with tractability from bottom to top, allows designers and engineers to quickly assess whether the original assumptions are still valid and efficient.

Establishing Value at the Highest Levels of System StructureSystems engineering is present, or can be present, at all levels of product structure. The typical view is that systems engineering disciplines are used to understand the most complex, multidisciplinary product structures. This is why the approach is so commonly used in aerospace and automotive products. However, the value of systems engineering thought and approach comes into play with any item that can be decomposed into multiple technologies and functions, as illustrated by the definitions cited in the previous section. The automotive OEM and most tiered suppliers have products that can be decomposed in this fashion, and in many cases can be decomposed several levels. For this reason we are faced with many levels at which the RFLP structures can be beneficial. In this paper we will focus on the highest level of composition. The benefits at this level of abstraction are often underestimated for reasons that we will explore.

Take, for instance, the typical vehicle structure and decomposition. We can start at the very highest level and identify requirements that reflect what the final customer is looking for in the vehicle they purchase. We often discuss requirements like safety, features, power, capacity, fuel economy, etc. Likewise, the functions that we describe will involve high-level capabilities like “provide seating,” or “allow direction adjustment.” Logical representations at this level will include some common platform definitions like chassis, powertrain, body, etc. Finally, the CAD definition of these logical objects might involve vague representations of package zones that “protect for” space that will be occupied by detailed components later to be developed.


Finally, we can go beyond part and sub-system reuse, and start to take advantage of system reuse. Having a well defined high-level definition of the product portfolio; firms can quickly establish an overall product direction, with a much richer set of assumptions and context with which to start development activities. This understanding at the requirements, functional, logical, and physical level provides much needed information to make higher level trade-off studies that are common in the conceptual phases. However, the reused system components accelerate the understanding and decision- making. This can be viewed as templatizing the systems engineering structures in much the same way that we create CAD templates to accelerate development of physical geometry.

Second, having a well established and thought out high-level system structure allows users to capture knowledge gained in the development process. Lessons learned through further design, decomposition, and modeling can be captured and used to shape the system structure for better refinement and understanding of high-level system decisions. For instance, if certain choices of power steering solutions are deemed unacceptable or incompatible for particular truck platforms, this information can be formalized at the highest levels so that incompatibilities can be avoided early in subsequent programs. Again, these may be captured and understood in a more complete fashion because they are not just reliant on requirements to dictate the process; they can leverage the functional and logical implications that cause the incompatibility. Therefore, future technologies can be more easily explored and understood, which potentially eliminate the incompatibility originally discovered.

Figure 2: RFLP Framework Illustration


Some “systems thinkers” may be very comfortable with the notion of using qualitative heuristics to guide them in the development of complex systems. However, one finds that without the proper framework to apply these valuable experiences and truisms, the value gained from them becomes difficult to consume, or even worse, they are mis-used and lead to improper decision making. For this reason, formalizing and extending the development framework beyond requirements structures and parts, taking advantage of the functional and logical structures, allows automotive professionals to better learn and execute over time. Vehicle and product architects can properly apply heuristics to platform representations at the correct structure, increasing the fidelity of understanding.

One of the difficulties in accepting the importance and value of high-level vehicle and product architecture is the lack of precise variables and concrete mathematical proof to evaluate and optimize the design at this level. The objects and scope of the definition at the highest levels of complex systems lack the desired precision that engineers come to expect when designing products. However, this working environment is commonplace for architects and artists. And in evaluating these works, architects and artists rely on heuristics to guide them in development. These heuristics are well suited for the highest level of systems structures because they allow development professionals to capture valuable principles from experts and past programs. These heuristics can then be applied to the structures that represent the development, including RFLP.

“Each generation knows more, learns more, plans more, tries more, and succeeds more than the previous one because it needn’t repeat the time consuming process of reliving prior experiences… By much the same process, qualitative heuristics, condensed and codified personal experience, came into being to compliment the equations and algorithms of science and engineering in the solving of complex problems5”


Once this foundation is in place, multiple levels of knowledge can be captured and applied to the system. At the lowest level of decomposition we are going to rely on precise numerical values to model and validate our system behavior. However, significant value can be had by understanding and focusing on the highest level of composition as well. In this space it will involve the effective use of higher level heuristic application, relying more on experience and knowledge in a qualitative sense as opposed to the precise quantitative application at the lower levels. Application of these tools will allow for a way to capture architectural context and learning, applying lessons learned much earlier in the development process for platform selection, and providing valuable context for detailed decision making later in the development cycle.

It is this shift from a tools-based viewpoint of systems engineering to a development-based viewpoint, as well as the appreciation for a heuristic approach to high-level systems engineering, that will allow automakers and suppliers to execute with great effectivity in all three aspects of cost, quality, and timing. This will provide a significant advantage to those that leverage this way of thinking about systems engineering.

Summary/ConclusionsSystems engineering will continue to play a prevalent role in the success of automotive OEMs and suppliers. As such, the industry will be looking for successful deployment of the discipline based on the needs of the enterprise and the desire to deliver successful products to their customers. However, definition of what constitutes systems engineering continues to challenge firms, even those that consider themselves systems thinkers. This challenge is overcome by viewing systems engineering as the core framework of development, and treating it as such by employing the right structures to understand, develop, optimize, and deploy designs successfully.

This approach involves going beyond requirements and parts as the core structures that we use in our development. It involves the addition of functional and logical structures in between, with implementation relationships between structures. The expansion of our development platform in this fashion provides us with exponentially more capability to understand and optimize our systems as we develop and deliver. The RFLP structure becomes the core structure with its own independent value from which other solutions can then leverage the understanding, and feedback information for future use and context. The functional objects allow development professionals in automotive to better understand “what” we are going to accomplish that will satisfy the requirements. The logical structure defines for us “how” we are going to accomplish these functions, leading up to the transformation to physical form for delivery. RFLP becomes the foundation, increasing the efficiency of the overall ecosystem of solutions used to develop, model, simulate, and deliver the system.

END NOTES1. INCOSE Systems Engineering Handbook version 3,

INCOSE-TP-2003-002-03, June 2006

2. Federal Aviation Agency (USA FAA) Systems Engineering Manual, definition contributed by Simon Ramo

3. Eisner, Howard, Essentials of Project and Systems Engineering Management

4. INCOSE Systems Engineering Handbook, version 2a, June 2004, page 11

5. The Art of Systems Architecting, second edition, Mark W. Maier and Eberhardt Rechin, 2002

© D

assa

ult S

ystè

mes

201

2, a

ll ri

ghts

rese

rved

. CA

TIA

, Sol

idW

orks

EN

OVI

A, S

IMU

LIA

, DEL

MIA

, 3D

VIA

, 3D

SwY

m, E

XALE

AD

, and

Net

vibe

s ar

e re

gist

ered

trad

emar

ks o

f Das

saul

t Sys

tèm

es o

r its

sub

sidi

arie

s in

the

US

and/

or o

ther

cou

ntri

es.

Dassault Systèmes, the 3D Experience Company, provides business and people with virtual universes to imagine sustainable innovations. Its world-leading solutions transform the way products are designed, produced, and supported. Dassault Systèmes’ collaborative solutions foster social innovation, expanding possibilities for the virtual world to improve the real world. The group brings value to over 150,000 customers of all sizes in all industries in more than 80 countries. For more information, visit www.3ds.com.

Visit us at3DS.COM

Delivering Best-in-Class Products

WI-SS 12-1205

Europe/Middle East/Africa Dassault Systèmes 10, rue Marcel Dassault CS 40501 78946 Vélizy-Villacoublay Cedex France

Americas Dassault Systèmes 175 Wyman Street Waltham, Massachusetts 02451-1223 USA

Asia-Pacific Dassault Systèmes Pier City Shibaura Bldg 10F 3-18-1 Kaigan, Minato-Ku Tokyo 108-002 Japan

Virtual Product Design

3D for Professionals

Realistic Simulation

Global Collaborative Lifecycle Management

Information Intelligence

Social Innovation

Online 3D Lifelike ExperiencesVirtual Production

http://www.3ds.com/products

http://www.3ds.com

http://www.3ds.com/company/about-dassault-systemes/dassault-systemes-in-the-world/

http://3ds.com/catia

http://3ds.com/solidworks

http://3ds.com/simulia

http://3ds.com/enovia

http://3ds.com/exalead

http://3ds.com/3dswym

http://3ds.com/3dvia

http://3ds.com/delmia

strategic systems - eds technologies

Documents