Dassault Systèmes %%%%

Category: Dassault Systèmes

26 Jun 2019

Requirements Simulation for Systems Engineers

Manage Complexity by Simulating Requirements

Requirements specifications are at the heart of the development process. Though multiple tools are used to manage requirements, it is still common for errors to creep in at the specification stage. Validation of requirements is usually carried out after the design phase, when hardware, software and models are simulated. These HiL, SiL and MiL (Hardware, Software, Model in the Loop) simulations are performed successively to validate the embedded systems against the requirements. If there are missing and incorrect requirements, this results in costly design and test iterations.

The dynamic nature of today’s intelligent systems makes it difficult to capture requirements under various operating conditions and system states. A model-based approach advocates the modeling of operating conditions and dynamic states, related functions, and the simulation of functional requirements – to detect and rectify issues with requirements before the detail design activity. Test vectors reflecting operating conditions and dynamic system states are then generated automatically. STIMULUS, the requirements simulation solution from Dassault Systèmes adopts the model-based approach and allows you to simulate and debug the requirements to find missing requirements, identify conflicting ones etc., in exactly the same way a software developer debugs code.

For a video introduction to STIMULUS, please click here.

WHAT IF… you could validate requirements before starting the design?

Model Executable System Specifications

Model formalized textual requirements, state machines and block diagrams in a fully integrated simulation environment. Textual requirements can be allocated at each level of the system’s functional architecture. Describe operating modes and sequences of dynamic systems with state machines.

Debug and Test System Specifications

Simulate the complete system specification (requirements, state machines and block diagrams) as a whole and find specification errors before the design phase, adopting an effective requirement, and test-driven development process. Generate many execution traces that satisfy system specifications and provides powerful debugging features to analyze requirements simulation results: automatic detection and diagnosis of conflicting and missing requirements, requirements coverage, highlight of active requirements, signal monitoring, etc. 

Validate Models in the Loop (MiL)

Once the behavior models and software code are built, validate the behavior against requirements. Build a test environment where requirements are turned into test observers, import behavioral models and software executables using the FMI® standard, generate numerous test vectors and run test campaigns and validate the behavior of the system under various operating scenarios. During test campaigns, compute and report comprehensive metrics on functional coverage of requirements.

Validate Control System Models

In most companies, debugging and testing of control systems is time consuming. Most often the focus is on validating the control systems using physical prototypes. However, very often engineers realize that issues have crept-in during the definition of the desired plant behavior and related requirements. It is also noted that many operating states have not been well covered by requirements and hence are not incorporated into the control models, resulting in re-work. 

Considering the ever growing complexity of plant operating requirements, it is best to simulate and test the requirements to ensure validity and coverage before starting the control system design activity. Also, test vectors for various operating conditions should be automatically generated based on the use-case conditions and re-used in the controls design environment. This eliminates the need to create test-cases once again in the control design environment.

Use-cases defined in STIMULUS are used to create test vectors as text files automatically, while the requirements are turned into MATLAB® observers that can be embedded in Simulink® models.

For a video presentation of these capabilities of STIMULUS please click here

Contact Adaptive to find out more about what 3DEXPERIENCE can do for you.

Ramesh Haldorai is Vice President, Strategic Consulting, 3DEXPERIENCE platform at Dassault Systémes.

19 Jun 2019

Deep Dive Into Dynamic Vehicle Systems Modeling

Let’s take a deep dive into dynamic vehicle systems modeling with a step-by-step example – modeling and simulating a series hybrid vehicle in Dymola®.

A series hybrid has an internal combustion engine that is only used to generate electricity. This means there is no direct connection from the engine to the wheels – instead electric motors are used to provide torque to the wheels.

This example not only demonstrates how components from different domains, like internal combustion engines and electric motors, can be combined to build a complete model of your vehicle, it also demonstrates how to model the control systems. 

To watch a prerecorded video of this scenario please Click here.

Step 1: Modeling the Engine and Crankshaft

We’ll start by modeling the internal combustion engine model. Models are typically created by dragging and dropping component models into a schematic diagram. Notice that the engine model has two inputs. The first input is used to specify the normalized throttle position for the engine and the other, a Boolean signal, used to specify whether fuel should be injected or not. We’ll revisit the topic of how to control this engine later. For now, we’ll send constant signals into the engine as a starting point and switch to a closed-loop control strategy later. To finish building the engine portion of our model, let’s add a rotational inertia of 0.15 kg m² to represent the crankshaft.

Note that the block diagrams used to model control functions are seamlessly combined with the mechanical components. More importantly, notice the difference in the connectors. The block diagram components have arrows on them, indicating information flows through the system. The mechanical connections on the other hand are directionless, acausal connectors. Acausal connectors allow us to build models that are flexible. In this case, we’ve connected the crankshaft to the engine model but we have the freedom to connect it to any other rotational component. We don’t need to worry about whether that component will be a spring, an engine, or a clutch; whatever is needed, we just instantiate it from the library and connect it up. 

Step 2: Modeling the Transmission

With the engine out of the way, let’s start looking at the transmission. Let’s model a simple transmission with a pair of motors from the standard library. One motor is connected to the engine, acting as the generator and the other is connected to the wheels, driving the vehicle. To control the motor, let’s insert a current control block. This component is essentially an actuator, controlled from outside the transmission. The input to this component is the requested motor current. The actual value for the requested current will have to be calculated based on the torque required by the vehicle. For now, let’s simply add a constant input with an initial value zero (motor is not running).

Next, we connect the generator and the motor, and add a ground to the circuit. Our mode is still missing one important thing: batteries to store energy. There are many ways to model batteries. Just to keep things simple, let’s use a large capacitor as the battery and add it in parallel with the motor. This means that electricity generated by the generator can flow either into the battery or into the motor. The motor current actuator determines how much flows one way and how much flows the other. To start the battery out charged, let’s specify the initial voltage of the capacitor as 300V. 

Step 3: Modeling the Vehicle

We’ll start with a simple model for the vehicle. The main effects we need to capture are how torque is translated into a force on the vehicle, the drag force present on the vehicle and the overall vehicle inertia. For this model, we are only interested in longitudinal dynamics, that is, we are only interested in modeling the vehicle moving in a straight line. The first step in modeling the vehicle is to add wheels that transform the torque generated from the transmission into forces that move the vehicle forward in a straight line. Note how the wheel model has a rotational connector on one end indicated by a gray circle and a translational connector indicated by green square to the other. Let’s also add the overall vehicle mass and a damper to represent losses that scale up with speed. In reality aerodynamic drag scales differently, this is just an approximation. So far everything looks good!

Step 4: Simulating the Behavior of the Vehicle

Step 5: Decomposing into Subsystems

To get closer to real-world conditions, we need to refactor this model and improve the control systems. We could start by changing and reconnecting components, but there are a couple things to watch out for. First, when reconnecting things, you run the risk of introducing errors. Second, we may want the original open-loop control version for testing. To address these concerns, we should follow standard configuration management guidelines.

Our first step is to organize the components by subsystems. To do this, we select the components that are part of the same subsystem and create a new subsystem model. Let’s create a new subsystem called EngineController out of the engine control components – the throttle indicator and fuel flag, while preserving the original components as a new model called OpenLoopController. We perform the same actions for the engine, transmission, transmission-control and vehicle models. The system is now composed of subsystems. The next step is to standardize the interfaces for each subsystem.

Step 6: Creating Interfaces

Let’s define a standardized interface for the engine-controller. In our model, the engine control decides what the throttle position should be and whether to fuel the engine. Our current engine control model reflects this by including two output signals. One is a Boolean signal for the fueling command and the other is a continuous signal indicating normalized throttle position. The current engine control model defines both the interface, the above two signals that it needs to work with, as well as the implementation, that it uses open-loop commands. We will separate this model into an implementation and an interface.

We’ll also add one additional input signal to the new interface to supply the engine controller with information about the state of the battery voltage.

We now have an interface which defines what is common across all potential engine control models and a specific implementation that just uses open loop commands. 

Let’s follow the same procedure for the engine subsystem, splitting it into an interface and a specific implementation. This interface includes inputs from the engine controller and an output shaft for connection to the transmission. The implementation includes the internal combustion engine and the crankshaft. We will follow this procedure for the transmission, the transmission-controller and the vehicle model, adding additional sensors along the way. 

Step 7: Creating Vehicle Architecture with Interfaces

To create the vehicle architecture, let’s build a new version of our system model, but this time, using only the interfaces that we have developed. After connecting the interfaces together, we end up with a model that looks very similar to what we had before, except this time we haven’t included any implementation details.

This architecture contains only the interfaces and no implementation has been specified. It captures the structure of our system, regardless of the specific implementations we choose to use. Once the architecture has been created we don’t need to connect subsystem models anymore, all the interfaces have been connected to work across any implementation. Next step is to create a variant of the vehicle and decide which implementations of each subsystem will be included in the variant.


Step 8: Extending the Vehicle Architecture to Implement a Variant

For the base variant, let’s recreate our original model with open-loop control. To do this we need to specify the implementations for each subsystem. At the moment, we only have one implementation for each subsystem. We could directly specify our implementation choices in the architecture model, but a better approach is to leave the architecture model as it is and create a variant from our architecture that captures our specific implementation choices. For this, we simply create a new model that extends from the architecture. When we extend the new model starts from the old model. From there, we can make further changes, like specifying the implementation details for the different subsystems. This allows us to easily create many different variants of the same fundamental architecture. All these models can exist at the same time instead of constantly switching back and forth between different configurations. It is worth pointing out that there is no limit to how many times we can extend from a model. For example, we might extend from our architecture to create a baseline configuration of our vehicle where all the implementations are filled in. From there, the engine designers might extend from the baseline model but insert a more detailed engine model while keeping the transmission and vehicle subsystem models the same. Similarly, the transmission designers might do the same with the transmission while leaving the engine and the vehicle as is. These best practices for configuration management organize the models and support collaborative workflows.

Step 9: Implementing a Closed-loop Transmission Controller

Once we’ve gone through and specified all of our initial implementations, we can again simulate the model. Of course, we’d still have the same uninteresting response because of the open loop elements, but now, we’re in a position to quickly do something about that. For example, let’s create a transmission controller that directs our vehicle to follow a specified speed profile. To do this, we’ll create a new transmission controller implementation by extending from the interface. When we extend, we are not copying the contents on the interface into our implementations. This is important because copying and pasting creates redundancy. By extending, we avoid copying and pasting, making maintaining the models easier. 

Once we create our new transmission controller model by extending from the appropriate interface, we just need to fill in the implementation details. Let’s instantiate a PID controller for speed control with a trapezoidal wave pattern for the drive cycle. 

To incorporate the new controller, instead of creating a whole new vehicle model, we can extend from the original open loop vehicle model and simply change our selection of the transmission controller. Again, we select the subsystem we are interested in, the transmission controller in this case, and we select from a collection of existing controllers. The relationship between different variants of our model is concisely captured. In this case, our current vehicle model, extends from the open-loop vehicle model, but replaces the transmission controller with a different transmission controller.

Step 10: Implementing a State Machine for the Engine Controller

Let’s repeat the procedure for the engine controller, extending from the interface to create a new model and implement a state machine to turn the engine on and off. Taking in the battery voltage as input, the state machine turns on the engine to charge the battery when the voltage is too low, and turns off the engine to save fuel, when the batter voltage is too high. To select this variant of the engine controller, we select the engine controller subsystem ad switch to this implementation. The variant choices in the architecture for each subsystem is automatically determined based on the interfaces they implement.

Step 11: Simulating Vehicle with the New Controllers

With these two new controller implementations, let’s take the vehicle out for a spin. After we simulate the model, we plot the vehicle speed and compare it to the desired drive cycle profile. Here we see the transmission controller is doing a good job of following the drive cycle speed trace. Now let’s look at what is going on with the engine and the battery. Notice how the engine comes on when the battery voltage gets too low and turns off when the battery voltage gets too high. Another important thing to know about the battery is that it is charging and discharging, even when the engine is off. The discharging comes when the vehicle accelerates because the motor takes energy from the batteries to increase the vehicle speed. But how is the battery recharging when the engine is off? The answer is regenerative braking. When did we implement regenerative braking? We did it in the transmission control. The PID controller in the transmission controller requests positive torque from the motor when the vehicle needs to accelerate, and requests negative torque when the vehicle needs to decelerate. Because we are using acausal models, all of our components include balance equations, for things like mass, momentum, charge and so on. In order for these balance equations to work out, the kinetic energy in the vehicle has to go somewhere. The motor turns it back into electricity when negative torque is requested and resulting current flows into the battery, charging the battery in the process.

The important point here is that we don’t need to implement regenerative braking. We implement a mathematical model of each component and then impose conservation equations across all the connections. As a result, we are always assured of accurate accounting. This is important because if model developers had to implement all the consequences of the different modes for each component it would be very easy to overlook something. With acausal modeling, all of this is taken care of. 

Next Step: Leverage the Vehicle Library to Model Your Vehicle

While it’s good to know that all of this is possible with Dymola, it is also important to realize that you don’t need to start from scratch. This architecture based approach is very common and many of the specialized libraries that come with Dymola include not only high quality component and subsystem models but also the interfaces and architectures that give you a head start in building models of your system. You can also import your legacy models into Dymola, either using direct interfaces, or by adopting the standard FMI® interface.

Vehicle Systems Modeling and Analysis (VeSyMA®) is a complete set of libraries for vehicle modeling and simulation. It includes engine, powertrain and suspensions libraries that work in conjunction with the Modelica® Standard Library. In addition, battery with electrified and hybrid powertrain libraries are available as well. Please watch the other videos in this series for more information on Dymola.

Contact Adaptive today to learn more about what our 3DEXPERIENCE solutions can do for you. Then, sign up for our newsletter.

Next Wednesday look for Requirements Simulation for Systems Engineers

Ramesh Haldorai is Vice President, Strategic Consulting, 3DEXPERIENCE platform at Dassault Systémes.

12 Jun 2019

Model-Based Systems Engineering

Introduction

In the 20th century, systems engineering methodology was developed so that a system could be decomposed into multiple sub-systems and each sub-system could be independently engineered, manufactured and serviced. The emphasis was laid on defining requirement specifications such that the sub-systems and its interactions with other sub-systems were clearly defined. This method emphasized upfront planning, analysis and specification. Hence, the term Requirements Driven Systems Engineering. In practice, it was always very difficult to specify upfront with a high level of accuracy and to resist changes to specifications during development. By and large this methodology has been inadequate and has led to delayed programs and last minute surprises, commonly referred to as the requirements-delay-surprise factor!

In the 21st century, iterative modeling and simulation play a crucial role in systems engineering. A operational model is first developed to understand all usage conditions, including the surrounding environment; then systems models are built and simulated; finally, component models are developed.

Change is integral to this methodology and requirements, structure, and behavior are derived and finalized with the help of the models. In short, the model as the master!

The fidelity of the models is continuously improved during the development and it is possible to substitute models with physical systems, also called, Hardware in the Loop (HIL). When they physical systems are assembled, they are just a twin of the model. Tests conducted on this physical prototype can be continuously correlated against predicted behavior and be used to improve the fidelity of models.

Models are Everywhere

It’s fairly common today for mechanical engineers to develop CAD models and subject them to structural, fluid and thermal simulation. Similarly, a number of models are built by engineers from other disciplines: software engineers use models to specify the operating conditions and interactions between systems, control systems developers build block-based models and generate software code for controllers; electrical engineers develop schematics and layouts of their design; electronics engineers develop high level logic that is synthesized into physical design; hydraulic engineers define hydraulic circuits. When interdisciplinary work is critical, co-simulations are also performed. For example, the thermal and fluid dynamics aspects are simulated together to understand the performance of the climate control systems.

Systems integration nightmare. Since each discipline is working on their own models, most often the first time the engineers witness how the systems function together is when they finally assemble a physical prototype. It’s not uncommon that the physical prototypes require numerous build, test, fix iterations, before they work as intended. The net effect: projects are delayed and quality suffers.

The era of autonomous systems. New types of sensors, complex control algorithms and the integration of on-and-off-board systems are the drivers of autonomous capabilities. This leads to an increase in software-based functionality and E/E complexity never seen before.

Even though models are used by every engineer, they are siloed by discipline, requiring physical prototypes for integration and validation.

Capture

Smart, Safe and Connected

Design, validate, deliver the intelligent vehicle experience

Smart, Safe and Connected Industry Solution Experience based on the 3DEXPERIENCE platform connects mechanical, embedded electronics and software development teams on an end-to-end digital platform and enables them to build a multi-disciplinary virtual prototype right from the early stages of concept design.

Make your vehicle models dynamics capable. If you are currently building control systems models in a signal-flow oriented tool, higher fidelity and more accurate control can be achieved by incorporation co-simulation of dynamic physical systems with Dymola.

Signal-flow oriented control models typically don’t fully incorporate dynamic vibrations caused by road and driving conditions. These vibrations affect driving comfort and safety, and if not incorporated in the models, may lead to issues discovered only later during physical testing. Simulating dynamic behavior under various road and driving conditions helps identify and fix issues in the early phases of product development.

Dynamic Systems Modeling and Simulation

The design and engineering of autonomous systems requires a new model-based systems approach – it needs to be multi-disciplinary from the get go! Dymola and the VeSyMA libraries are a capitalization of decades of experience with dynamic systems modeling.

Dymola is a physical modeling and simulation environment, for model-based design of dynamic systems. Dymola adopts the Modelica language and is accompanied by a portfolio of multi-disciplinary libraries covering the mechanical, electrical, control, thermal, pneumatic, hydraulic, powertrain, thermodynamics, vehicle dynamics and air-conditioning domains. Library component models are coupled together to form a single complete model of the system. You can extend existing models or create custom models, improving reuse across projects.

Vehicle Systems Modeling and Analysis (VeSyMA™) is a complete set of libraries for vehicle modeling and simulation. It includes engine, powertrain, suspensions libraries that work in conjunction with the Modelica Standard Library. In addition, battery with electrified and hybrid powertrain libraries are available as well.

Model Import and Export. You can import models directly from Simulink® into Dymola. Dymola also supports the FMI Standard 1.0 and 2.0 for both model exchange and co-simulation.

Real-time Simulation. Dymola supports real-time code generation for simulation on a wide range of HiL platforms from dSPACE®. Co-simulation of Dymola and Simulink generated code has been tested and verified for compatibility with multiple combinations of dSPACE and MATLAB® releases.

Driver-in-the-Loop Simulation. Dassault Systèmes’ partner, Claytex, integrates Dymola with driving simulation software. Libraries built by Claytex include a car template and support for LiDAR, radar and ultra-sound sensor libraries that work with the simulator. Before exporting the model, simulation can be run in a test environment within Dymola as well.

Systems modeling case-study: Energy management of trucks at Arrival. www.arrival.com

Source: energyengineering magazine. Low Carbon Vehicle special edition – Summer 2016

The electrification of trucks involves efficient energy management and also needs to maintain the vehicle attributes at the same level as a conventional powertrain system. Hence, it requires detailed studies of vehicle system interactions in order to understand the vehicle system that dominates these attributes. The upfront modeling approach is vital to capture these attributes before developing the physical prototype.

Dymola has a multi-physics modeling capability that is very useful in developing these complex interactions at both vehicle system level and sub-system level, and for pin-pointing the dominant systems or components. All of these vehicle systems/subsystems can be modeled within the same modeling workspace at the top level and then cascaded to a lower level in order to create a series of libraries that can be repeatedly used for different vehicle plant model architectures. This process is important for system modeling, particularly during development phase, giving engineers access to different options to optimize the system architecture for energy management and the improvement of other vehicle attributes. The process minimizes the design and product risks by not committing tooling costs for the prototype build, as the majority of the validation activities can be simulated to produce results that are a close representation of the physical system/sub-system components, which also reduces the development lag-time. Another advantage of system modeling is being able to perform component sizing optimization for energy management in order to improve the vehicle range.

Dynamic Physical Systems Modeling - A Checklist

If you want to incorporate dynamic behavior into your vehicle models, the following are some of the key capabilities of the modeling environment that you may want to consider.

Breadth of Library Models: Are there pre-built libraries for the sub-systems that are included in your system? If your systems are multi-disciplinary in nature, look for libraries across multiple domains containing models for mechanical, electrical, control, thermal, pneumatic, hydraulic, powertrain, thermodynamics, vehicle dynamics, air conditioning, etc.

Object Oriented: Can you directly instantiate the library models and build your systems with ease? Typically, look for a drag and drop interface. Also, look for the ability to abstract subsystems in a single model. If necessary can you modify the library models and create your own derivatives of the models? Model management capabilities are a key requirement if you are working in a team.

Equation Based: Can the dynamic behavior of systems be described by differential and algebraic equations? Does it support the concept of flow and across variables?

Acausal: Does the environment support the definition of equations in a declarative form? Without considering the sequence? This reduces the effort to describe behavior in comparison with procedural languages like C and other block-based tools, where signal flow direction needs to be considered.

For a review of Dymola capabilities, please click here.

Contact Adaptive to find out more about what 3DEXPERIENCE can do for you.

Next week: Dynamic Vehicle Behavior Simulation – A Deep Dive

Ramesh Haldorai is Vice President, Strategic Consulting, 3DEXPERIENCE platform at Dassault Systémes.

22 Mar 2019
3DEXPERIENCE

3DEXPERIENCE 2019x Takes Collaboration to New Heights With Its Latest Release

Dassault Systèmes’ recent release of 3DEXPERIENCE R2019x boasts over 200 new features and functions. With its cloud capabilities, role-based functionality, and all the apps on one dashboard, it provides a revolutionary level of collaboration and user experience.

This release widens the lead Dassault has as the largest cloud offering, for businesses of any size, in the PLM industry. In fact, it encompasses 95% of the most advanced and comprehensive design & engineering portfolio on the market.

Let’s take peek at the basics of the platform and then jump right in to some of the highlights.

3DEXPERIENCE Platform

People with different skills and roles, and located in various locations, need to work together. Open and easy collaboration as well as data compatibility throughout the design, manufacturing, and production processes are vital in developing innovative products successfully.

The 3DEXPERIENCE Platform offers two configurations:

  • Business Innovation – digitally connecting all users, and
  • Industry Innovation – collaborating across industries and disciplines

This cloud platform provides a single, easy-to-use, role-based interface. There are software solutions for the entire creation process and for every organization in the company, from engineering to marketing and sales.

Hundreds of roles, such as Mechanical & Shape Designer, Product Release Engineer, Supply Chain Director, Collaborative Forecaster, and Platform Manager, are embedded into four major areas—3D Modeling, Content and Simulation, Information Intelligence, and Social and Collaboration applications. Roles easily allow users to select apps and services with one click.

The nice thing about the interface is that the apps and services are all available on the 3DDashboard (shown below).

Key Highlights of the 3DEXPERIENCE New Release R2019x

Real-time User Collaboration with the 3DDashboard

  • My 3DDashboard

3DDashboard delivers real-time intelligence and improved collaboration for the Business Innovation Role.

Users can see everything that’s happening all on one dashboard 24/7. They can analyze data from all sources, visualize and review 3D designs in real-time, and share dashboards, insights, and files. Data is compatible throughout the company, from creating ideas to manufacturing the end product. Users can navigate, review, and compose assemblies at an extraordinary pace.

  • Web Notes Enhancements

R2019x added a rich text editor and Search enhancements along with Merging and Duplicating by drag & drop. Concurrent editing prevents another user from erasing content previously added on the same app instance.

  • 3DDrive

Organize, manage, and share files with peers (only in the cloud).

  • 3DReview of Projects

Seamless interaction and rapid switching between apps in your dashboard allows 3D review on projects.

  • A NEW Users Group App Improves Productivity Up To 5X

This app was a hot topic. You can now invite multiple users, instead of just one, to join 3DEXPERIENCE where roles are assigned to each user. Then they are added to relevant communities, dashboards, and 3DSpace for easy collaboration. This helps to improve productivity up to 5X.

New Experiences for Designers to Create in 3D

  • 3DPlay

Users can visualize 2D and 3D content directly from a browser in 3DPlay and on multiple devices to speed up design iterations.

It includes enhancements to the 360 images with support for spherical and cylindrical images.

Fly Walk was updated to enable a user to benefit from Touch support, Align to Ground feature, and automatic speed depending on the size of the model.

Support for seamless switching between Full 3DPlay and 3DMaster apps like 3DReview and 3DCompose.

3DPlay now supports the new “advanced Filters” in 3DSpace (Web).

  • 3DNatural Sketching for an Immersive Experience

Designers now have the ability to transform 2D ideas into 3D virtual reality using the CATIA Natural Sketch. Designers can plug-and-play their HTC Vive head mounted display to jump into VR from their 3DSketching app and instantly design and model in 3D VR space creating an immersive experience.

  • The 3D Generative Innovator

This 3D mobile, browser-based, generative modeling (wireframe and surface design) replaces programming with graphical visual scripting (low code approach) combined with interactive 3D modeling.

This intuitive approach allows the creative experts in Architecture, Design/Styling, and Engineering to quickly explore, design, and validate options for complex, irregular shapes and patterns. Unique to this function, the user can swap between the interactive 3D and the graph. This capability pushes creativity and helps users to be more productive leading to more successful designs.

Enhanced Security

  • 3DPassport

3DPassport provides a higher level of security through authentication and authorization with Single Sign-On (SSO) Services along with 2FA Authentication.

  • 3DCompass and General Data Protection Regulation (GDPR)

3DCompass delivers compliance with General Data Protection Regulation (GDPR). It offers data protection and privacy regulations on the cloud.

Improved Admin Capabilities

  • 3DCompass and Native OS Applications

3DCompass allows Platform Admins to download and install Native OS applications.

CATIA V5 launcher, SOLIDWORKS Desktop, and any third party app can be installed and fully functional to access the platform for Simulation, Manufacturing, Collaboration, and Engineering capabilities without migrating or translating CAD data.

Enhanced End-to-End Additive Manufacturing (AM) Solution

  • Generates optimized conceptual assemblies refining the shape globally or locally.
  • Digital continuity. Extends AM digital continuity and enhance AM from function-driven design, optimized process, and realistic manufacturing, to bringing the model from Virtual to Real with the Make service of the 3DEXPERIENCE Marketplace. Digital continuity is unique to Dassault Systèmes end-to-end AM.

Summary

These are just a handful of the powerful and unique enhancements Dassault Systèmes recently released in 3DEXPERIENCE R2019x. It gives PLM, without a doubt, a revolutionary level of collaboration and user experience on the cloud.

People can work smoothly together regardless of location, device or role and streamline their workflows. They can quickly develop ideas and design concepts in 3D, test and experiment in real time, assess challenges early on, and share accurate, up-to-date data. This all leads to creating innovative products more effectively and successfully.

Get more details on over 200 new features and functions in 3DEXPERIENCE R2019x here.

Watch the overview video below:

To find out more about how the 3DEXPERIENCE Platform can help you overcome your challenges in bringing new products to market, contact us.

 

 

20 Mar 2019

Adaptive Corporation Receives Platinum Designation in the Dassault Systemes VS Partner Program

Adaptive Corporation, the leading Digital to Physical Product Lifecycle Company, was again honored by being named a Platinum Partner in Dassault Systèmes Value Solutions channel for 2019, continuing the status from 2018. The Platinum Partner designation is reserved for Partners that are highly engaged in Dassault Systèmes’ business and identified as best-in-class performers in the 3DS ecosystem. The award is based on Key Performance Indicators (KPIs), which measure expertise in sales performance and efficiency, strategic alignment, and commitment. Other partner designations are Gold, Silver, and Bronze.

“This recognition from Dassault Systèmes is an honor for us at Adaptive,” said Eric Doubell, CEO of Adaptive Corporation. “We are in great company at the Platinum level with very tough competition in the Value Solutions channel. It all starts with a desire to provide the very best solutions to our customers and look forward to continuing those relationships.”