Unmanned Autonomous Vehicle (UAV) systems have become possible in recent history thanks primarily to the effects of Moore’s Law — the doubling of processing power every 18 months. This trend, coupled with improvements in sensors and actuators, has enabled the advanced signal and data processing necessary to control UAVs. However, the complexity of UAV systems has taxed traditional design workflows, and revealed numerous challenges such as shorter design cycles, greater performance and reliability demands, and cost constraints.

As a consequence of these stresses on the traditional component-centric design process, the engineering community has turned to Model-Based Development (MBD) to help accelerate and manage the development process. MBD processes rely on software models to move as much of the design process onto software as possible, with an eye on reducing the number of physical prototypes, achieving optimal performance, and improving system reliability. Ultimately, the MBD process aims to get better products to market faster, thus saving time and increasing profits.

Figure 1 shows a high-level view of an MBD process, typically called a V-diagram. On the whole, the process begins with requirements and ends with testing the actual product. In other words, it begins with modeling and design, and ends with testing and validation and verification (V&V).

Though this modeling paradigm has been in place for at least the last decade or more, there is a recent push for system- level models for the purpose of Concept Design. Models for Concept Design play three roles:

  1. To confirm that requirements are met (connection to Requirements and Specifications);
  2. To generate meaningful topologies and bounds on parameters to the virtual prototyping tools (connection to Detailed Design); and
  3. To provide fast and accurate models for “x”-in-the-Loop Simulation (xILS) (connection to System Test).

System-Level Requirements Need System-Level Models

Figure 1. A high-level Model-Based Development V-diagram.

Requirements originate from the markets for which a product is being designed. They are a statement of criteria that must be satisfied for a product to be successful. In the case of UAVs, “The UAV must never crash,” or “The UAV must have a range of 100km,” would be examples of system-level requirements. The results of these requirements are specifications that serve as benchmarks to guide the detailed design of components and subsystems. For example, the latter requirement might necessitate a specification for a particular minimum fuel capacity and maximum UAV mass.

In the past, the focus has been on component- and subsystem-level modeling and design, relying on the developers of the numerous specifications to ensure that no problems would occur once the complete system was integrated. Generally speaking, software solutions exist to alleviate problems within a single domain: CAD packages look for mechanical stack-up problems, EDA tools can handle massively complex circuit layouts and predict manufacturing defects, and numerous other vertical solutions exist for application domains like hydraulics, thermal, etc.

However, predicting and mitigating negative interactions between these domains has been pernicious. These interactions are either expected or unexpected. Modeling the expected coupling between domains has been accomplished either manually or in great detail at the component level. For example, consider a servo driver circuit with MOSFETs connected to a heat sink. A design engineer may ask the question, “How does the temperature of the MOSFETs relate to the heat they are generating?” The answer to this question depends on a variety of electrical, thermal, and fluid properties. Modeling this interaction would typically require a lightweight low-fidelity hand-derived solution using lumped parameters (e.g. “The heat capacity of the heat sink is X°C/J”) and governing physical equations, or a heavyweight high-fidelity 3-D simulation solution, like COMSOL or NASTRAN. Unexpected interactions are typically left unexposed until physical prototypes are created. A more ideal tool would capture the physics across multiple domains, strike a balance between fidelity and speed, and predict the dynamics of complete systems.

Figure 2. To design this quadrotor helicopter, MapleSim was used to develop high-fidelity 3-D dynamics models of the system and its flying characteristics.

While this is very attractive in theory, without the right tools it is very difficult to achieve in practice. However, new system- level modeling tools have sought to capture the complete dynamic behavior of a system including all of its physical domains. In the high-performance world of UAVs, the design engineer from the previous example could now ask a more meaningful question based on the system- level requirements and on the dynamic interaction of the various subsystems: “Will my necessary yaw rate still be possible as my MOSFETs heat up?”

An additional benefit of a system-level model is its tendency to expose unwanted interactions between subsystems. For example, resonances between domains (like a rotational resonance coupling with a magnetic field resonance), and unintended positive feedback loops (runaway heat generation) can be detected and mitigated early on.

At Maplesoft, we have developed such a system-level modeling and simulation platform, called MapleSim. Built to take advantage of symbolic technology, MapleSim allows complex multidomain systems to be modeled quickly, and then generates the governing dynamic equations for the system. This unique approach produces highly concise representations of the system model that are fully parameterized for further analysis and optimization, either in the tool’s integrated analysis environment, Maple, or in third-party tools. Moreover, MapleSim automatically generates ANSI-C code from the model that is extremely efficient, allowing levels of detail to be implemented in real-time that are not possible with other tools.

MapleSim is used in a wide variety of industries and projects, including the design of UAV systems. For example, Quanser Inc., manufacturers of robotic and mechatronic systems including high-quality haptic devices, used MapleSim to develop the QBall, a quadrotor helicopter. With MapleSim, they were able to fully capture the dynamics of the gyroscopic effects, something that is extremely difficult or impossible to treat with traditional tools as developing the necessary high-fidelity models by hand is difficult and time consuming. Not only did they achieve a high-fidelity model in very little time, but they were also able to uncover behaviors in the system they had not taken into account. Quanser engineers were able to efficiently evaluate different configurations in the software before settling on the final design.

What Does the Future Hold?

Figure 3. MapleSim 6 provides enhanced support for Modelica, the open-standard modeling language for describing physical models.

Historically, the simulation and analysis part of the design process has been a separate activity from the core design activities performed with CAD tools, but increasingly these two processes are merging into a more integrated design process. Sometimes called Model-Based Systems Engineering (MBSE), this approach sees the dynamic simulation of the whole system at the Concept Design phase of the design process, but takes this a step further. It would be possible to store the functional behavior of subsystems and assemblies as dynamic models in a database with all the other product information, such as physical attributes and operational constraints. The initial design steps could then be automated — the design team simply enters the product requirements and the system offers up some candidate configurations that would fulfill, or almost fulfill, those requirements.

MBSE and Configuration Management (CM) are two areas of research that aim to make the above a reality. From Maplesoft’s perspective, there are several areas of development that we consider to be critical to the success of this activity:

  1. A rich, consistent, multidomain model description language that allows all dynamic behaviors to be characterized for systems that contain many engineering domains, such as electrical, mechanical, hydraulic, pneumatic and thermal. While there have been several attempts at this over the years, one language - Modelica - is emerging as the de facto standard. Developed by a consortium of universities and industrial partners, Modelica has been widely adopted in Europe and is seeing increasing adoption in North America and Asia. MapleSim is the first commercially available Modelica tool to be developed in North America and Maplesoft is active in ensuring Modelica fulfills the requirements of system-level engineering within its customer base.
  2. Tight integration between many analysis tools. MapleSim is described as a 1-D (i.e., timedomain) lumped-parameter simulation tool. This allows for rapid model development and simulation execution and provides good insight into a system’s overall functional behavior. However, it is often necessary to include more complex elements from, for example, finite element (FE) or computational fluid dynamics (CFD) tools. To achieve this, there is a growing demand on a standard framework that would allow this level of interaction between tools. The MODELISAR project, initiated by the Modelica Association, has been instrumental in defining such a framework. Called the Functional Mock-up Interface (FMI), it provides the ability for tools to interact.
  3. Integration with CAD tools. At some stage in the design process, it is necessary to either extract physical design parameters from a CAD design or submit optimized design parameters into it. Maplesoft has developed interfaces with various CAD tools and these are being further developed to achieve this goal.
  4. Integration with all other operational information. To make CM a reality, it is necessary to include all operational information with the functional behaviors of a component or system model: envelopes of operation, failure modes, environmental factors, even manufacturing processes and costs, all need to be considered. This is an area of very active research, much of it driven by the demands of military vehicle manufacturers. At the core of this research is the Object Management Group (OMG) and the International Council on Systems Engineering (INCOSE), out of which extensions to the Modelica language are being developed using SysML.

MBSE is in its infancy but is rapidly turning into a reality, and manufacturers need to factor this into their product development and business strategies for the future. Ultimately, MBSE holds the promise of dramatically reducing development effort in multidomain engineering products, reducing risk of design flaws and getting to market faster.

Early System-Level Modeling is the Key

In summary, the overarching key to effective MBD is that complex products, like UAVs, need to be considered as whole systems in order to understand how the multitude of subsystems interact with each other over the entire range of duties. This needs to be done very early in the design stage so that as the design evolves, the functional behavior can be validated throughout the process, thus ensuring it continues to fulfill the design goals of the product.

This article was written by Derek Wright, Product Manager, Maplesoft (Waterloo, ON, Canada). For more information, Click Here 

Defense Tech Briefs Magazine

This article first appeared in the February, 2013 issue of Defense Tech Briefs Magazine.

Read more articles from this issue here.

Read more articles from the archives here.