Teaming up on design and test
No longer isolated disciplines, design and test work together, and test tools are taking on design tasks.
By Rick Nelson, Editor in Chief -- Test & Measurement World, 8/1/2009 2:00:00 AM
|
See other articles from our August 2009 issue. |
Powerful high-level software tools give domain experts in such diverse fields as aerospace engineering and medical electronics increasing control over the design and verification of embedded systems. What’s more, the tools themselves are adapting, with graphical design environments intended for test now aiding the design process, and design, modeling, and simulation tools enabling such techniques as HIL (hardware-in-the-loop) testing.
 A BA609 tilt-rotor aircraft undergoing flight testing flies in airplane mode over the Alps in northern Italy; the photograph was taken from an Italian Air Force cargo plane. Courtesy of Bell/Agusta Aerospace. |
During a panel discussion at the Embedded Systems Conference 2008, the idea of domain experts supplanting electrical engineers gained some currency (Ref. 1). A look at the current state of affairs does suggest that domain experts and high-level systems architects—as opposed to coders and processor experts—have gained significant ability to participate throughout the embedded-system-design process. But the need for C coders and hardware engineers is not going away. What’s occurring in most cases is that domain experts and EEs are collaborating to get increasingly complex products to market quickly.
Commenting on the 2008 panel discussion during a May 2009 interview, Jim Tung, a fellow at The MathWorks, said, “The premise was that people who have to implement an embedded system and the people who know what needs to be implemented never know how to talk to each other. Certainly the world has moved away from that starting point. What you certainly do see now is collaboration. The people who have the implementation skills needed to deliver a device with a certain power consumption and performance profile can work more effectively with the domain experts—the people who know what the functionality needs to be.” High-level languages like The MathWorks’ Matlab and Simulink, he said, are what enable that collaboration to take place.
Test software addresses design
Another firm that sees opportunities in working with domain experts is National Instruments. NI has been promoting its LabView graphical design software, which initially served test-and-measurement applications, as a tool for embedded-system design. An NI spokeswoman explained, “With the thousands of technical challenges the engineering community faces today within application spaces like medical, robotics, and green, we don’t have enough embedded engineering experts to address all of these problems. Therefore, the masses of domain experts out there become a critical part of helping the engineering community out. We’ve seen numerous domain experts be very successful using our graphical system design tools to design embedded systems in the medical, robotics, and renewable energy industries, and we will continue creating new embedded hardware and software tools that allow any domain experts and scientists to innovate themselves and design embedded systems.”
  The Visica 2 cryoablation system for the treatment of tumors (left, courtesy of Sanarus) went from a requirements document to first revenue in 14 months, according to systems engineer Jeff Stevens. Stevens used LabView to develop code for the CompactRIO platform (right, courtesy of National Instruments) that served as the embedded engine in the Visica 2. |
One NI customer that has successfully used NI tools in embedded-system design is Alliance Spacesystems, which makes mechatronics systems such as robots for NASA (Ref. 2). Shelley Gretlein, LabView real-time and embedded product marketing manager at NI, described the company’s mechatronics group as a multidisciplinary team comprising aerospace, mechanical, electrical, and control engineers all cooperating on the same team. Said Gretlein, “You see much less pure EE or strong embedded experience. Much more, you see people coming from different backgrounds to build these systems.”
The move to the embedded space has been an evolutionary one for NI, but that doesn’t mean NI is moving away from test. Todd Dobberstein, product manager of industrial and embedded technologies for National Instruments, said, “Test is NI’s bread and butter—we’ve been dealing with test and data acquisition since we started as a company.” The company’s test expertise, he said, complements the design capabilities inherent in LabView. In fact, said NI’s Gretlein, the group she works with at Alliance Spacesystems began as a test customer and has increasingly adopted NI tools for design, leading to a unified tool chain.
PJ Tanzillo, biomedical segment lead and embedded software manager at NI, cited another customer who has successfully applied NI’s tools in an embedded-system design project: Sanarus, which used the tools as it developed the Visica 2 cryoablation system for the treatment of tumors. Tanzillo described the systems engineer on the project, Jeff Stevens, not as a domain expert but as an EE by training whose expertise is at the systems-architecture level—rather than at the coding and hardware-optimization level. Such systems architects may be able to apply their talent across multiple disciplines, from robotics to medical electronics, but, said Tanzillo, they understand the underlying technology, albeit not necessarily down to the level of developing a driver for an ADC (analog-to-digital converter) or writing HDL (hardware description language ) code for an FPGA (field-programmable gate array).
Designing the Visica 2
I spoke with Stevens to get his views on domain expertise and embedded-system design. He described himself as a systems engineer with degrees in EE who had never written any code that would see the light of day. That changed, he said, when he joined Sanarus in November 2005 as principal systems engineer and faced a four-month window to develop a fully functional prototype of the Visica 2. “As the system architect, I could see that we’d need a custom PCB [printed-circuit board] for the microprocessor and all the I/O, and we’d have to outsource all the firmware because nobody at Sanarus spoke software. That was the approach Sanarus had followed on its existing product, but that product was an order of magnitude simpler than Visica 2.”
 Traditionally having served test applications, the LabView graphical design environment is taking on design chores for embedded systems. Potential hardware targets include the modular Compact-RIO and the Single-Board RIO. Courtesy of National Instruments. |
Further making the task challenging was the small team available to work on the project. The four-person team included a project manager, a mechanical engineer, and a “supertech,” who had a degree in psychology but was creative at prototyping and could solder circuit boards. All in all, said Stevens, “I was thinking eight months might be enough to accommodate board and code spins plus integration, but four months fell squarely in the 'no way’ bucket.”
At that point, he met with representatives from NI and investigated the company’s CompactRIO platform as a hardware target for embedded code that could run software that he could develop on LabView—a tool he had heard of from the test operations of companies he had worked for but had never used. He presented his case to Sanarus management and got approval to adopt the NI approach. With the help of NI support personnel and a developer from Cal-Bay, who spent a week teaching him LabView best practices, he said, “I comfortably hit the working prototype in the four-months target.” He added, “Visica 2 went from a requirements document to first revenue in 14 months, which is pretty good for an invasive medical device. The Wall Street Journal awarded Visica 2 the runner-up prize for medical devices in its 2008 Technology Innovation competition [Ref. 3].”
Higher levels of abstraction
The Visica 2 project was one that was completed without the intervention of traditional embedded-system designers. But that may be the exception that proves the rule. Tung at The MathWorks elaborated, “Think about the 'good old days’—if you wanted high-performance software running on your desktop, you had to write in assembler.” Subsequently, he said, “optimizing compilers have reduced the need for people to work at that level, so they are able to work at a higher level of abstraction—let’s say C code.”
Domain experts, Tung said, will want to work at an even higher level of abstraction, with Simulink, for example, and he added that automatic code generation has reached the point where the resulting code is efficient enough in terms of memory and provides sufficient throughput to satisfy many applications. “However,” he said, “there are still times when you need to really tune and optimize that implementation, so the need in an embedded system for somebody to write in C code hasn’t gone away.”
Tung added, “If I am gong to write something and really fine-tune it at the C code level, I only want to do that once. If I’m going to hand write something, then a high-level modeling language, like Simulink, should be able to encapsulate it and make it available to the system-level engineers so they can look at the design exploration tradeoffs and make a much more informed decision. And [the encapsulation] facilitates reuse.”
Domain experts vs. systems architects
As did Tanzillo at NI, Tung distinguished between domain experts and systems engineers or architects. Although NI promotes LabView for both, Tung said that domain experts working at the algorithmic level would more often use Matlab, while of Simulink users, he said, “I think in an increasing number of cases they will be multidomain in their perspective.”
Tung also noted that apart from performing system design, users of high-level tools can leverage them to perform verification. He explained, “Let’s take a case in automotive suspension systems. You’ll have the model of the suspension systems and the algorithms that will be describing the damping and other behaviors, but you will also have the portion of the models that will be describing road surfaces, vehicle dynamics, driver behavior, and all the other things important to understanding if the suspension will do what you want. One portion of the models that describes the suspension system can automatically generate the code that goes into the microcontroller, and it ships as part of the car. The other portion of the models essentially becomes the basis for the test bed—you essentially generate code for that other portion of the models comprising the road surface, the vehicle dynamics, and the driver, and you run that in a real-time HIL system that essentially is the test bed.”
Fly-by-wire at Bell Helicopter
I asked David King, principal engineer at Bell Helicopter, about trends with domain experts. He said, “Looking back 15 years when we did some of our legacy fly-by-wire development programs, we had a much larger proportion of specialists for low-level programming languages on our team. Now if we look at the proportion of the team, the majority of them are not well versed in the low-level languages, but they are more or less system-level engineers using the model-based design process.” He said the shift seems to be gradual, and in good news for embedded-system designers, he added, “I don’t see that we are dropping our number of specialists in the programming languages, but we are growing on the systems side, so the proportion is changing.”
King is currently working on the Bell/Agusta Aerospace BA609 aircraft project, which he described as the world’s first commercial, nine-passenger, tilt-rotor vehicle. The 609 program provides some perspective, he said: “We started with model-based design 11 years ago, in the summer of 1998. That was even before the term 'model-based design’ was coined. What we did was put together a process using Matlab and Simulink to try to take out some of the manual steps in the process, such as hand coding from design data. And the one thing that’s interesting is it’s not just hand coding for the embedded source code, but it was the hand coding for all the analytical tools that are used to analyze the various aspects of the aircraft and system performance,” including simulation, development of the test cases, and verification.
King said Bell still uses hand-coded embedded software in the flight-control computers on the aircraft but uses the autocoded models for all the analytical tools to perform simulation, structural analysis, stability analysis, and test-case generation, all of which, he said, represented “a big chunk of the workload.”
King added, “I am really seeing the benefit of model-based design in that we can have one model of the aircraft and the flight-control system that is in a very usable format, and that model is used by various disciplines to do analysis. For example, we use it for simulation to analyze dynamic loads and to analyze handling qualities. We use it for real-time simulation with the pilot in the loop, and we also use it for non-real-time evaluation when we are checking stability and control characteristics.”
King indicated he expects the trend toward an increasing emphasis on high-level tools to continue, noting, “If you look at the toolset and the maturity of the tools that The MathWorks produces and that the industry is using now, they’ve progressed quite a bit since we started [the 609] program 11 years ago. For our next programs, we are looking at additional automated steps, including [generating the] embedded software.”
A version of this article appeared in the July 9 issue of EDN.
| REFERENCES |
|
No related content found.
- 0 rated items found.
Datasheets.com Electronic Parts & Inventory Search
185 million searchable parts
- Part Number
- Description
- Inventory
- Products
- Manufacturers
View All Webcasts
