Thursday, July 26, 2012

Electronics markets showing signs of recovery


Electronics markets bounced back strongly in 2010 from the 2008-2009 recession. The recovery stalled in 2011 as a series of natural and human-made disasters hit various parts of the world. Japan was hit by an earthquake and tsunami in March 2011. Thailand was affected by floods which disrupted HDD production and thus impacted PC production throughout the world. The European financial crisis led to economic weakness in most of the European Union (EU).

Recent government data on electronic production and orders shows most regions are beginning to recover from the 2011 slowdown. The chart below shows three-month-average change versus a year ago in local currency for electronics orders (U.S. and EU) and production (China and Japan). The data is through May 2012, except for the EU which ist hrough April. China continues to show the most robust growth, with double digit growth since the beginning of 2010. U.S. electronics orders experienced 12 months of year-to-year declines from March 2011 through January 2012, but turned positive in February 2012, reaching 6% growth in May. Japan electronics production change was negative for 16 months, with declines greater than 20% for six of those months. In May 2012, Japan electronics production turned positive at 2.3%. EU electronics orders remain weak, with April 2012 the twelfth consecutive month of year-to-year declines.



Unit shipments of PCs, mobile phones and LCD TVs have not yet reflected the above recovery. International Data Corporation (IDC) estimates PC unit shipments versus a year ago have been flat or in the low single-digit range for seven quarters through 2Q 2012. A bright spot has been media tablets, which have shown explosive growth since Apple released its iPad in 2Q 2010. Numerous competitors to the iPad have emerged from Samsung, Amazon and others. Media tablets in many cases are displacing PC sales. Combining unit shipments of PCs and media tablets results in a more realistic picture of this market segment. The combined data shows sturdy growth in the double digit range through 1Q 2012.


Mobile phone shipments were fairly sound with double-digit growth through the first three quarters of 2011. Shipments have weakened since, with 1Q 2012 down 1.5% from a year ago. Within the mobile phone market smart phones have shown vigorous growth, over 40% for the last three quarters. IDC estimated smart phones accounted for 36% of the total mobile phone market in 1Q 2012, double the percentage from two years earlier. Smart phones are a key driver for the semiconductor market due to the high semiconductor content. Smart phones also benefit mobile service providers through increased data usage and provide growth opportunities for app developers and accessory makers.

LCD TV unit shipments have also been weakening over the last two years, according to Display Search. 1Q 2012 LCD TV units were down 3% from a year ago compared to year-to-year growth averaging over 30% in 2010 and 7% in 2011. 3D LCD TVs are emerging as a meaningful segment of the market, accounting for 14% of LCD TV shipments in 1Q 2012 versus just 4% in 1Q 2011.

Despite the overall weakness in electronics and semiconductor markets, some signs are pointing towards a resumption of healthy growth. Two of the key drivers of the new recovery, media tablets and smart phones, have just emerged as significant markets in the last few years. 3D TVs may drive growth in an overall flat TV market. Economists generally expect the overall world economy will show higher growth in 2013 than in 2012. An improving economy and the new electronics market drivers should lead to relatively strong electronics and semiconductor markets in 2013.

Author: Bill Jewel
Source :http://www.semiwiki.com/

Thursday, July 19, 2012

Advanced switches customize, optimize automotive HMIs

Author: Owen Camden, Source: www.eetimes.com

User interface is an extremely important aspect of any vehicle “experience.” Obviously, electromechanical components, such as switches, in automotive applications must provide high reliability and long operating life. But these switches must also add to the look (design) and feel (functionality) of a vehicle’s keyfob, center console, steering wheel and other in-cabin interfaces.

Known in the industry as “haptics,” the touch, feel, and sound of a switch’s actuation are paramount to a user’s experience and impression of a particular vehicle. Automotive design engineers want user interfaces to respond and provide feedback in specific ways that are unique to their vehicle.

Essentially, user feedback is part of the identity of a vehicle and its manufacturer. Haptic features are often customized for specific vehicles and manufacturers, and are often accomplished through advanced switch configurations. These switches must combine ruggedness with design flexibility to meet automotive requirements

Sealing




A commonality of every harsh environment application is the need for ruggedized components that can withstand the brutal environmental conditions. Switches sealed to IP40, IP65, IP67 and IP68 specifications that are resistant to contamination by, dust, dirt, salt, and water are necessary in automotive applications.



Combating environmental elements is often accomplished with switch designs featuring an internal seal to protect the switching mechanism, as well as an external panel seal designed to keep liquids from entering the panel or enclosure. Silicon rubber caps are also employed to prevent the ingress of fluids that could adversely affect the function of standard switches. Additionally, the materials used in these switches, such as PBT (polybutylene terephtalate), must be robust under exposure to chemicals, water, and other potential contaminants.

Rugged switch designs for automotive vehicles also need to be resistant to extreme temperatures, vibration, and shock. Depending on the specific application within or outside the vehicle, advanced snap-acting, tactile, pushbutton, and toggle switches are available with IP67/IP68 ratings that provide high levels of reliability and predictability.

Reliability and predictable behavior is directly linked to the compatibility of the switch based on the mechanical environment of the unit and the final OEM specification. Switch manufacturers must simulate the potential environmental conditions a switch will encounter over its operating life to ensure their design achieves the specified robustness.

Haptics

As the gateway to a user interface, a switch configuration must have a desirable appearance, feel, and sound. Switch manufactures must work closely with automotive makers to optimize aesthetics, ergonomics, and performance.

For typical switching functions in automotive applications, such as front-panels and dashboards, robust pushbutton switches are often utilized. Sealed up to IP68-ratings, pushbutton switches can be designed to provide excellent tactile feedback with specific travel and actuation forces. Pushbutton switches also provide a long operating life of more than one million cycles, making them to be well-suited for use in automotive vehicles.

Ultra-miniature tactile switches are ideal for keyfobs, as they combine a high-operating life with long-term reliability and low current compatibility, while a snap-switch would most likely be used in a vehicle’s fob reader. Both switches can be customized to provide precise feedback.

The audible response of a switch is another important way for vehicle manufacturers to differentiate their vehicles. This feature can be customized to deliver a specified sound or click when actuated. Automotive OEMs are focusing more on these sound responses and consider the acoustic response as part of their branding. The audible response is highly dependent on the switch design, and vehicle manufacturers need to get the same sound response for all units, regardless of the advanced switch configuration.

In order to provide solutions that deliver repeatable audible responses, switch manufacturers have developed established platforms that allow designs to carry over to different applications. These switches provide high-reliability and consistent haptics in an “automotive proven” series, while also achieving drastically reduced development cost and time.

Implementing new technologies
Consumers are by now familiar with touch screens in their smart phones, vehicle infotainment systems, navigation/GPS systems, and even computer monitors. Similarly, touch sensing controls, including tactile screens, can now be implemented into almost any electronic device, including center console interfaces. The “clicker” function (see below) can be enabled with any touch-sensitive surface, and provides uniform haptics over any surface. The simple mechanical system integrates low-profile tactile switches with the actuating superstructure to provide a clickable touch sensing system.


Based on a structure with supporting points, the actuator collects and transmits the force from the touching surface to the switch with a minimum of distortion or power consumption. Pressure on any surface will apply a force on the supporting points at the edge, which will then in turn send back the force to middle arms and then to the appropriate tact switch. The technology is more efficient than “hinged” solutions by providing a smooth and uniform click. Multiple configurations, structures and profiles can be developed depending on the application and room available for integration, from 2.5 to 10 mm.

In addition, the clicker technology can combined with multiple key areas based on the same actuating surface. The keys/buttons are managed via touch sensing in that each area is used for pre-selection of the function. Selecting the function is managed by actuation on the whole surface. The main benefit is that instead of managing separated keys/buttons, the unit can be managed by a single flush surface with haptics, reducing integration issues and simplifying some features like key alignment, backlighting, and tactile difference between keys.

Assembly

In terms of assembly and maintenance, electromechanical components for automotive applications often feature quick connections that support modular installation so that they can be plugged into the panel and locked firmly into place, simplifying both assembly and maintenance. This arrangement also lets the OEM store individual switch elements separately and configure them during final assembly to meet application-specific needs, while saving storage space and costs.

One such example of this is seen with illumination, as automotive vehicles contain a large number of visual indicators for informational and safety purposes, signifying the current state or function of vehicle’s features. LED indicators can be mounted independently of the switch and interfaced with an IC that controls it for slow or fast blinking, or to produce various colors that indicate the status.

Adding illumination at the switch level significantly reduces materials costs, as some switch designs with optional illumination allow users to order the base switch with or without the cap, providing the ability to order one base switch together with multiple color caps, or snap-on caps, during the installation process to suit each specific application. This modular solution not only allows OEMs to have fewer part numbers to inventory, thus simplifying materials and assembly processes, but it also gives engineers greater flexibility with circuit and panel designs.

Manufacturers have also developed pushbutton switches that offer panel-mounting options to help simplify assembly. Rear panel-mounting switches, such as C&K’s rugged pushbutton switches, are ideal for applications where multiple switches are going to be mounted to a PCB. Customers can mount them to the PCB first, then the entire assembly can be installed into the armrest or panel. This allows for a much easier installation compared to traditional front mounted switches that require the mounting hardware to be tightened from behind the panel, which is sometimes hard to access; as well as having to run all the leads to the mating connectors on the PCB. Rear mounted switches allow customers to install the hardware from the top and still achieve the same look while simplifying the installation process.

Custom electromechanical solutions
OEMs are approaching electromechanical component manufacturers for more than just switches. By utilizing a switch manufacturer for designs beyond the switch itself, increased flexibility in overall design can be realized. Switch dimensions are becoming more critical, making it imperative to work closely with customers to discern all details. Today, it is less about the switch being mounted to a PC board or adding wire leads or a connector to the switch, and more about defining the issues that need to be solved. Because switch manufacturers are now dealing with the entire module, they are spending an increasing amount of time with customers to determine how the module is being impacted in the application to assess potential challenges that were not previously considered.

By working closely with customers in all phases of the design process, switch manufacturers can identify materials that interface with the operator, and those in the actual contact mechanism can be re-evaluated and altered to conform to performance, reliability, lifespan, and robustness standards. For example, some manufacturers are now offering switch packages with multi-switching capability and high over-travel performance, with various core-switching technologies such as opposing tactile switches or a dome array on a PC board. Such packages often include additional PC board-mounted integrated electronics, custom circuitry, and industry standard connectors for the complete package.

Still other solutions optimized for automobiles, such as interior headliners, feature not only customized switches with insert molded housing and custom circuitry and termination, but also paint and laser etched switch button graphics and decoration capabilities, as well as backlighting for nighttime use. Today, switch manufacturers are doing even these customized graphics and decorations in-house.

Conclusion
Although the electromechanical components are some of the last devices designed or specified into a center console, dashboard, or steering wheel, switches are one of the most important components in a system—and one of the first components a vehicle operator contacts. Each automotive manufacturer has different performance requirements, external presentations, internal spacing, and footprint restrictions. As such, each vehicle requires different packaging and orientation of switches to achieve the functional and performance objectives. Customized haptic options (actuation travel, force, and audible sound), ergonomic options (illumination, decoration, appearance), sealing options, circuitry configurations, housing styles, mounting styles (including threaded or snap-in mounting), and termination options are integral to meeting these application requirements.

Combining innovative electromechanical designs with complete switch assemblies often affords customers greater flexibility and customization options that reduce assembly and manufacturing costs while improving performance and reliability. Working closely with the switch manufacturer to solve design problems and implement customized performance requirements can yield faster time-to-market by streamlining the prototyping and production ramp-up stages, thereby bringing the finished product to market more quickly.

Thursday, July 12, 2012

Integrating IDE and RTOS for ARM-based development


Author: John Carbone, Express Logic
Source: www.eetimes.com
Embedded systems employing ARM 32-bit processors support application software that can deliver excellent product functionality and benefits. Faced with the challenge of developing such applications, developers seek robust, powerful development tools to help them bring complex products to market faster that are optimized to perform better than the competition.Rather than settling for "free" or "cheap" tools, commercial developers recognize the benefits of paying more for quality tools and achieving quality results. In this rapidly evolving and competitive market, only the strongest will survive. Manufacturers are well advised to consider the ROI from the best tools available, rather than to seek the lowest cost tools that might leave their product with a competitive handicap in time-to-market and performance.

Developers today need a comprehensive development environment (IDE) and a real-time operating system (RTOS) to help them develop and achieve optimal performance for their application. But not only do developers need the best IDE and RTOS they can find, they need them to operate together to achieve maximum benefits. Each must be of high quality in its own right, but beyond that, they must be engineered to work together and to support each other’s strengths.The steps involved in the development of an embedded application are similar across the spectrum from small to large. A simple example can therefore be used to illustrate how the capabilities of an integrated IDE and RTOS make real product development easier and more effective. The Host-Target configuration might look something like this:

Developing an embedded application involves many steps, including:
Application design
Write source code
Compile code
Link libraries
Download executable to a target board
Run the program on the target
Set breakpoints
Stop the program
Analyze data from the running application

Each of these steps can be handled by an IDE, with its component editor, compiler, linker, and debugger.Especially in the more complex applications, the developer might elect to use an RTOS to schedule application threads, pass messages, and use semaphores and mutexes. The RTOS also should be able to capture event trace information in real time, and enable those events to be viewed graphically on the host. This is critical in a real-time system, since so much happens so quickly that a “big picture” view helps sort things out. An event trace display shows exactly what RTOS services and application-defined events each thread has performed. It also can collect and summarize performance statistics including a complete execution profile, a summary and individual display of all context switches, and a wealth of other useful information.An example application

To illustrate how these RTOS/IDE capabilities can work together to help the developer, consider a simple application. The application consists of 8 threads, "thread_0" through "thread_7." These threads each perform a particular function in an endless loop. The threads are each assigned a priority, from 0 (the highest) to 1024 (the lowest). At any point in time, the RTOS runs the highest priority thread that is “READY” to run. A thread is READY when it is not waiting for anything outside of its own code – for example, waiting for a message to arrive from another thread. In such instances of waiting, a thread is "SUSPENDED" and is not READY to run. Here is a summary of what each thread does:The RTOSA priority-based, preemptive scheduling RTOS, ThreadEx, is used in this demo to manage the eight application threads. Using this example, developers can also understand several services, including messaging, semaphores, mutexes, and sleep and experiment with them in code of their own.To follow the application’s flow and specific actions, the RTOS time-stamps each event and stores related information regarding the event in a circular buffer on the target. This buffer is uploaded to the host and displayed there to reveal the time-based flow of events.The IDEIAR Embedded Workbench for ARM is the development IDE for this demo. This IDE has been tightly integrated with the RTOS, and 4 areas of integration are noteworthy:Project Compatibility. The RTOS is provided in a format that enables it to be used from within the IDE’s project structure. All source code is syntax compatible with the IDE’s compilers and assemblers, making the RTOS ready to use right out-of-the-box.RTOS Awareness. This IDE plug-in captures and displays a wealth of information for all application threads and other defined objects, each time the system is stopped (at a breakpoint or a HALT command).One such display, shown above, is the “Execution Profile.” This is a unique information capture and display that shows profiling information for the application’s threads, interrupt system, and idle time, with a separate breakdown by thread. Note the overall application profile, showing the breakdown of execution time by Idle, Interrupt, and Application. Also, note the individual thread performance profile. As you can see, threads 1 and 2 indeed dominate performance, as described earlier.Macro Operations. Using the IDE’s Macro capability, the IDE can automatically and optionally upload the trace buffer to the Host at a breakpoint. This simplifies and speeds up the process of running the program and then viewing the event trace to see what happened.Launch an External Tool. Another convenient capability enables the launch of an external tool through the “Tools” menu. This can be used to quickly and easily launch a software systems event analyzer—from the IDE.

The Application BuildNormally, to build an application, the developer would have to go through the following steps:Create a new projectAdd a source file to the projectType in the source codeBuild the RTOS libraryAdd the necessary board initialization filesSet compiler, linker, library, and other configuration settingsBuild the application In an IDE with tight RTOS integration, the task becomes much simpler and less error-prone. The RTOS is provided with a sample application, which includes a pre-built RTOS library, application source code, header files, initialization code, and linker directives. It is intended for debugging, with all profiling and trace operations activated, and minimal optimization.This enables the developer to immediately scan the demo code, study the project settings, and only make changes where desired.Breakpoints and MacrosBefore running the application, the developer might set a breakpoint in the code for “thread_0.” Since this thread runs every 10ms, it provides a predictable point at which to examine the events that have transpired over that period of time.Each time this breakpoint is reached, the value of thread_0_counter increments by one, as shown in the debugger’s Watch Window, where expressions can be viewed. But also, the trace buffer can be uploaded automatically from target memory to the Host. This is helpful in case the developer decides to view the events. This is where the IDE’s macro capability can be used. A macro can be performed by the debugger by listing the macro in the breakpoint edit window, as shown below.This is a powerful capability that has many uses. In addition to executing a macro, developers can instruct the program to “continue” after encountering the breakpoint or remain stopped at the breakpoint. We also can tell the debugger not to stop for the first “n” occurrences of the breakpoint, and stop on the “n+1”. Also, a Boolean expression or condition can be evaluated and used to determine whether to stop at the breakpoint. These features give the developer tools to use to help examine what is happening at a particular point in the programRTOS AwarenessMany IDEs offer RTOS Awareness, but all RTOS Awareness implementations are not the same. In addition to tracking all application threads and kernel objects (semaphores, mutexes, queues, etc.), IAR Embedded Workbench for ARM also displays the RTOS Execution Profiling information. In our example, it provides a view of all threads. This is just one of several views available. Note the tabs for other views.Event TraceAn event trace can be a most useful tool for understanding the behavior of a real-time system. While stopped at a breakpoint, we can easily view the events with a single mouse-click, thanks to another IDE capability – the ability to launch an external tool.In this case, the external tool we launch is TraceX, which runs on the Host and provides a timescale view of system events and it can be used to measure the time between events. This provides a valuable measurement tool for determining the time taken to progress from one point of a program to another. As shown below, the highlighted span is 172.5 microseconds. By highlighting the start and stop events of interest, developers have a handy means of examining not just what was done, but how long it took.

Summary: An IDE that is tightly integrated with an RTOS can simplify many of the otherwise tedious operations that a developer must perform in order to run and debug an application. Beyond assuring correctness, this information enables developers to optimize the performance of the application, and to make tradeoffs between responsiveness and throughput, which are often opposing goals.

Verification claims 70% of the chip design schedule!

Human psychology points to the fact that constant repetition of any statement registers the same into sub-conscious mind and we start believing into it. The statement, “Verification claims 70% of the schedule” has been floating around in articles, keynotes and discussions for almost 2 decades so much that even in absence of any data validating it, we believed it as a fact for a long time now. However, the progress in verification domain indicate that this number might actually by a "FACT".

20 years back, the designs were few K gates and the design team verified the RTL themselves. The test benches and tests were all developed in HDLs and sophisticated verification environment was not even part of the discussions. It was assumed that the verification accounted for roughly 50% of the effort.

Since then, the design complexity has grown exponentially and state of the art test benches with lot of metrics have pre empted legacy verification. Instead of designers, a team of verification engineers is deployed on each project to overcome the cumbersome task. Verification still continues to be an endless task demanding aggressive adoption of new techniques quite frequently.

A quick glance at the task list of verification team shows following items –
- Development of metric driven verification plan based on the specifications.
- Development of HVL+ Methodology based constrained random test benches.
- Development of directed test benches for verifying processor integration in SoC.
- Power aware simulations.
- Analog mixed signal simulations.
- Debugging failures and regressing the design.
- Add tests to meet coverage goals (code, functional & assertions).
- Formal verification.
- Emulation/Hardware acceleration to speed up the turnaround time.
- Performance testing and usecases.
- Gate level simulations with different corners.
- Test vector development for post silicon validation.

The above list doesn’t include modeling for virtual platforms as it is still in early adopter stage. Along with the verification team, significant quanta of cycles are added by the design team towards debugging. If we try to quantify the CPU cycles required for verification on any project, the figures would easily over shadow any other task of the ASIC design cycle.

Excerpts from the Wilson Research study (commissioned by Mentor) indicate interesting data (approximated) –
- The industry adoption of code coverage has increased to 72 percent by 2010.
- The industry adoption of assertions had increased to 72 percent by 2010.
- Functional coverage adoption grew from 40% to 72% from 2007 to 2010.
- Constrained-random simulation techniques grew from 41% in 2007 to 69% in 2010.
- The industry adoption of formal property checking has increased by 53% from 2007 to 2010.
- Adoption of HW assisted acceleration/emulation increased by 75% from 2007 to 2010.
- Mean time a designer spends in verification has increased from an average of 46% in 2007 to 50% in 2010.
- Average verification team size grew by a whopping 58% during this period.
- 52% of chip failures were still due to functional problems.
- 66% of projects conitnue to be behind schedule. 45% of chips require two silicon passes and 25% require more than two passes.

While the biggies of the EDA industry are evolving the tools incessantly, a brigade of startups has surfaced with each trying to check this exorbitant problem of verification. The solutions are attacking the problem from multiple perspectives. Some of them are trying to shorten the regressions cycle, some moving the task from engineers to tools, some providing data mining while others providing guidance to reduce the overall efforts.

The semiconductor industry is continuously defining ways to control the volume of verification not only by adding new tools or techniques but redefining the ecosystem and collaborating at various levels. The steep rise in the usage of IPs (e.g. ARM’s market valuation reaching $12 billion, and Semico reporting the third-party IP market grew by close to 22 percent) and VIPs (read posts 1, 2,3) is a clear indicative of this fact.

So much has been added to the arsenal of verification teams and their ownership in the ASIC design cycle that one can safely assume the verification efforts having moved from 50% in early 90s to 70% now. And since the process is still ON, it would be interesting to see if this magic figure of 70% still persist or moves up further!!!

Author: Gaurav Jalan Source: www.semiwiki.com

Sunday, July 1, 2012

Software extends hardware-in-the-loop real-time simulation



Software extends hardware-in-the-loop real-time simulation

Author: Tina George, Source: www.eetimes.com



Somewhat similar to automotive development, in the space industry the design, building and testing of planetary rover prototypes is extremely expensive, and system testing typically does not occur until late in the design/testing process—leading to a long, protracted development time. In response to such timing issues, Amir Khajepour, Canada Research Chair in Mechatronic Vehicle Systems and engineering professor in the Mechanical and Mechatronics Engineering department at the University of Waterloo (Canada), and his team worked with the Canadian Space Agency (CSA) and Maplesoft, to develop a hardware-in-the-loop (HIL) test platform for solar-powered planetary rovers.

The CSA has a strong history of applying symbolic techniques in space robotics modeling—having used these techniques in the design of various space robotic systems deployed on the U.S. Space Shuttle and the International Space Station. This new HIL initiative uses MapleSim, the latest generation of Maplesoft's symbolic modeling technology, to rapidly develop high fidelity, multi-domain models of the rover subsystems.
The team's approach allows component testing within a simulation loop before a full rover prototype is available, essentially creating a virtual testing environment for the component under test by “tricking” it into thinking it is operating within a full prototype. Using the MapleSim modeling and simulation tool, high fidelity and computationally efficient models were created for this real-time application.
With this test platform, scenarios that are hard to replicate in a lab setup (such as the Martian environment) or components that are not yet available, can be modeled while hardware components that are available can communicate with these software models for real-time simulations. The goal is to progressively add hardware components to the simulation loop as they become available. In this way, system testing takes place even without all the hardware components, bridging the gap between the design and testing phases.
The main advantage of this approach is that it significantly reduces the overall project development time. In addition, this method allows for component testing under dangerous scenarios without the risk of damaging a full rover prototype.
Rover kinematicsBesides simulating the rover dynamics, the MapleSim modeling environment was used to automatically generate the kinematic equations of the rover.

These equations then formed the basis for other tasks in the project such as HIL simulations, rover exploration-path planning, and power optimization. The modular system setup also enables users to quickly change the rover configuration and explore different approaches in a short time.
Hardware-in-the-loop frameworkThe figure below shows an overview of the test platform. Information regarding the rover’s position, orientation, tilt, speed, and power consumption (obtained from dynamic models of the rover) is used as input to the software models. A library of rover components was developed within MapleSim and imported within LabView Real-Time where the HIL program and GUI of the simulations were developed. The program was then uploaded to the embedded computer within National Instruments PXI, where communication between the hardware components and the software models was established and the real-time simulation run.

“Due to the multidomain nature of the system (mechanical, electrical and thermal), it was desirable to model all the components within one modeling environment such that critical relationships can be easily discovered. In addition, computational efficiency is crucial in real-time simulations,” said Khajepour. He added, MapleSim was found to be an excellant environment for the application because of its multidomain abilities, use of symbolic simplification for higher computational efficiency, and ease of connectivity to LabVIEW.”
Development of custom components and power managementIn addition to making use of MapleSim’s built-in component library, custom components were also readily developed. A model to estimate the solar radiation that a tilted surface (i.e. solar panels) would receive on Mars was implemented using MapleSim’s Custom Component Block. This model took into account the sun’s position, the rover’s latitudinal and longitudinal position as well as orientation and tilt as it traveled from point A to point B. This was used together with a solar array model (see figure below) to estimate the power generation of a rover throughout the day.

“The intuitive nature of MapleSim allowed my team to create high fidelity models in a short period of time,” said Khajepour. “This played a key role in the success of this modular HIL test platform which allowed for component testing, power level estimation, as well as the validation of power management and path planning algorithms.”
The team also used MapleSim as a tool in an earlier part of the project to develop the power management system of the autonomous rovers. They used the software to rapidly develop high-fidelity, multidomain models of the rover subsystems. The goal was to develop a path planning algorithm that took rover power demands (and generation) into account. Using the models developed, the path planner determined the optimum path between point A and point B, such that the rover maintained the highest level of internal energy storage—while avoiding obstacles and high risk sections of the terrain.
Step one of this three-year project was to develop the initial rover model, including such aspects as battery, solar power-generation, and terrain and soil conditions. Including a full range of HIL testing phases with real-time hardware and software using system models was critical for optimizing system parameters that maximized power conservation while still achieving mission goals.
“With the use of MapleSim, the base model of the rover was developed in a month,” says Khajepour. “We now have the mathematical model of the 6-wheeled rover without writing down a single equation. MapleSim was able to generate an optimum set of equations for the rover system automatically, which is essential in the optimization phase.” The symbolic techniques that lie at the heart of the software generate efficient system equations, without loss of fidelity—thus eliminating the need to simplify the model manually to reduce its computational complexity.
GUIKhajepour also noted the graphical interface. In MapleSim, a design engineer can readily re-create the system diagram on his/her screen using components that represent the physical model. The resulting system diagram looks very similar to what an engineer might draw by hand. MapleSim can then easily transform the models into realistic animations. These animations make it substantially easier to validate the system diagram and give greater insight into the system behavior.
“The ability to see the model, to see the moving parts, is very important to a model developer,” says Khajepour. “I am now moving to MapleSim in most of my projects.”