STRATEGIC SYSTEMS
Engineering for Functional and Logical Structures
Contents
3Abstract
3 Introduction
4Evidence of Systems Engineering
4Increasing Value of Systems Engineering
6 The Current Framework:
Requirements and Parts
8The New Framework:
Requirement, Functional,
Logical and Physical (RFLP)
10 Functional and Logical Overview
11Establishing Value at the Highest Levels
of System Structure
14Summary/Conclusions
15References
Take Control: Intellectual Property Whitepaper
© 2012 Dassault Systèmes
Abstract
Introduction
Mechatronics 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.
Systems 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.
Whereas most frameworks for requirements-driven
model-based design support a single discipline, what
is really needed is a framework for requirementsdriven 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èmes
3
Strategic Systems Engineering for Functional and Logical Structures
Evidence of Systems
Engineering
Organizational Amnesia Stifles Innovation
Similarly, 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 electromechanical 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.
First, 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.
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.
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.
Strategic Systems Engineering for Functional and Logical Structures
4
© 2012 Dassault Systèmes
Increasing Value of Systems Engineering
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.
Systems 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”
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
“Systems engineering is an interdisciplinary
approach and means to enable the
realization of successful systems.4”
© 2012 Dassault Systèmes
5
Strategic Systems Engineering for Functional and Logical Structures
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.
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?
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.
The Current Framework:
Requirements and Parts
The 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
Strategic Systems Engineering for Functional and Logical Structures
6
© 2012 Dassault Systèmes
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.
© 2012 Dassault Systèmes
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.
7
Strategic Systems Engineering for Functional and Logical Structures
The New Framework:
Requirement, Functional,
Logical and Physical (RFLP)
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.
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.
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.
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.
Strategic Systems Engineering for Functional and Logical Structures
8
© 2012 Dassault Systèmes
“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.”
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
“Tdeveloping
he central idea
and understanding
behind Incium cor
complex products.magnia que prem et est, occabor
Table 8.1: Major System or Architectural Views
Perspective or view
Description
Purpose/objective
What the client wants
Form
What the system is
Behavioral or functional
What the system does
Performance 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
© 2012 Dassault Systèmes
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
9
Strategic Systems Engineering for Functional and Logical Structures
Functional and Logical
Overview
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.
Up 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.
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
Figure 2: RFLP Framework Illustration
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
Strategic Systems Engineering for Functional and Logical Structures
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.
10
© 2012 Dassault Systèmes
Establishing Value at the
Highest Levels of System
Structure
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.
Systems 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.
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.
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.
© 2012 Dassault Systèmes
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.
11
Strategic Systems Engineering for Functional and Logical Structures
Figure 2: RFLP Framework Illustration
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.
Strategic Systems Engineering for Functional and Logical Structures
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 decisionmaking. 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.
12
© 2012 Dassault Systèmes
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.
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.
“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”
Strategic Systems Engineering for Functional and Logical Structures
13
© 2012 Dassault Systèmes
Summary/Conclusions
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.
Systems 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.
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.
END NOTES
1.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
Strategic Systems Engineering for Functional and Logical Structures
14
© 2012 Dassault Systèmes
Virtual Product Design
Global Collaborative Lifecycle Management
3D for Professionals
Information Intelligence
Realistic Simulation
Social Innovation
Virtual Production
Online 3D Lifelike Experiences
© Dassault Systèmes 2012, all rights reserved. CATIA, SolidWorks ENOVIA, SIMULIA, DELMIA, 3DVIA, 3DSwYm, EXALEAD, and Netvibes are registered trademarks of Dassault Systèmes or its subsidiaries in the US and/or other countries.
Delivering Best-in-Class Products
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.
Europe/Middle East/Africa
Dassault Systèmes
10, rue Marcel Dassault
CS 40501
78946 Vélizy-Villacoublay Cedex
France
Asia-Pacific
Dassault Systèmes
Pier City Shibaura Bldg 10F
3-18-1 Kaigan, Minato-Ku
Tokyo 108-002
Japan
Americas
Dassault Systèmes
175 Wyman Street
Waltham, Massachusetts
02451-1223
USA
Visit us at
3DS.COM
WI-SS 12-1205