Embedded.com Industry Comment

Modeling the way with academia and industry

Jim Tung

6/1/2010 3:53 PM EDT

When I visit companies around the world, I see some recurring themes. The systems they are developing are more complex and perform more functions than ever before. These systems typically include combinations of existing subsystems, off-the-shelf components, and custom subsystems. The development is performed through collaborations of engineering teams representing multiple disciplines, often in different companies or locations around the world.

These companies have found that their traditional development processes are insufficient to address increasing system complexity, the pressure to shorten time-to-market, and customer demands for more functionality with higher quality. As a result, they have modified or completely transformed their development processes to exploit the use of models. They have stopped relying on paper-based specifications, and instead use models as executable specifications that clarify and communicate requirements and specifications. They use multi-domain models to simulate the system-level behavior of their designs. They simulate the subsystems adjacent to their design when the real subsystems are not available or haven’t yet been developed. They automatically generate code for embedded systems from algorithmic models. And they leverage models as test cases and hardware-in-the-loop simulations to test and verify their products and systems. This approach, known as model-based design, is being used in diverse applications, for large and small projects, with co-located and geographically-distributed engineering teams.

These companies are looking to engineering schools to produce engineering graduates with the skills to take full advantage of model-based design. Engineers are asked to think about engineering at a “systems” level rather than only being a specialist in a single domain. They require stronger modeling and analytical skills, not simply an ability to prototype. And, of course, those newly hired engineers must also have a strong foundation in engineering concepts and mathematics.

But large gaps exist between industry needs and engineering education when it comes to modeling. In 2009, the IEEE Control System Society conducted an informal survey of academic and industry members to evaluate the capabilities of engineering graduates. One question asked of the members was, “What areas (if any) need to be strengthened or added to the curriculum to better prepare control engineers for industry?” The responses showed strong consensus across academia and industry about the areas for improvement: hands-on experience, industry-focused design, computer hardware and software, and mathematical modeling of dynamic systems.

The survey also pointed out the discrepancy between what is needed and what is delivered. Over 90% of the industry respondents said that simulation models for system verification or product design, nonlinear models, real-time models for hardware-in-the-loop verification, and experimental system identification methods are useful and valuable skills for controls engineers in industry. Yet, less than 50% of the university respondents said that those are “topics covered in a course or courses that you regularly or occasionally teach, and that would typically be completed by entry-level control engineers graduating from your institution.”

Some universities have taken significant steps to expose engineering students to modeling and simulation techniques, particularly in controls, signal processing, and mechatronics labs. Senior-year design projects are increasingly team-based, not individual, and frequently involve building and sharing models. GM, the primary sponsor of the ChallengeX and EcoCAR student competitions for fuel-efficient vehicle design, considers modeling and analysis to be so important in its own processes that it required the student teams to model, simulate, and analyze their design extensively for a year of the three-year competition before even having access to vehicles.

About the author
Jim Tung has more than 25 years experience in the technical computing software markets. He is a 20-year veteran of The MathWorks, holding the positions of vice president of marketing and vice president of business development before assuming his current role focusing on business and technology strategy and analysis. Jim holds a bachelor's degree from Harvard University.





hriedel

6/3/2010 9:29 AM EDT

Strange, can not see my comments... Well, just again then:

Well, I remember my time in university, and modelling and design was taught but not that extensively. At least we had a project using CASE5.0 and Rational Rose and had to compare the approaches of SA/SD and OOAD. But overall, most students are packed with tasks and duties to do, which does not really give much time to really explore all the features, besides being able to ask someone knowledgable. And most of the time, projects are to small to modelling. Besides that, most tools at the time where feature limited, like you can model but not generate code, and the license to a full-fledged tool was too expansive. I believe, even now, most people can not afford a license e.g. for rhapsody (i know there is a modeler edition, but then you have just a model, without the possibility to simulate them!). OSS tools like Topcased open the ways but they are also not perfect and in steady flux of features and stability. Then when you try to get into UML/SysML, tools like Rhapsody state they are UML2.0 or SysML1.x conform, but then you realize, there are some things missing to the standards, or just different.

Also, what is missing in models is the tools are sometimes just a hinderance to the work, hiding much into a model, or dependencies are hidden in the embedded code editor. You try to find your way through the model and finally get lost.

When i had a voluntary internship at Bosch, it was my first time working with a test(!) version of Labview. After the 8 weeks of battling with Labview, I got my task done. Matlab/MathCad? Well, never really had the possibility to get acquainted with in university, most of the time, they just threw us some examples, that's it. Now.. well Matlab is out of range of my pocket, and at work, nobody gives you the time to learn it. Get your job done.

The next is to cope with a approach. But with every year, two or three approaches are pushed thorugh town, where you say, "Well, yeah, but didn't we do that already? Isn't that just a new BS bingo buzzword?" -driven design - add waht you like for . But the most stupid one I recently read here was 'requirements-driven-design'!

Sign in to Reply



KarlS

6/3/2010 1:40 PM EDT

I have never seen a successful design that wasn't the result of evolution/iteration. What the designer needs is tools that allow the design to start with a few basics and grow incrementally. Unfortunately, the snob appeal of all the pie-in-the-sky-magic tools methods dwarfs the reality. One method that never seems to return: Start with a block/flow diagram of the basic function and write the expressions that define the data manipulation and the control logic in a clear and concise manner so there can be no ambiguity in understanding what it does. Now give the designer a quick turnaround tool so when a function has to be added it is as easy as possible to see how it fits in with the basic flow.

Instead tools start with the assumption that the design is complete and jump right into building the chip.

Just because something is academically POSSIBLE does NOT mean it is the right thing to do. A cpu CAN be programmed to do any logical function ... If it cannot do it in time FORGET IT!

HDL can describe any logical function ... that is AFTER the bad coding practices have been taken care of and you finally are able to read the code, if you can remember the question after browsing page after page of it.

Sign in to Reply



Dr Marty

6/8/2010 2:25 AM EDT

I've seen way too many students get to the end of their degrees having simulated everything but who are still 'scared' to build a real circuit. "What? You mean I should actually go down to the electronics shop, buy the components and breadboard, and solder it together?"

There is no substitute for getting hands on with real hardware. Unfortunately that takes time and it's much cheaper to run a lab of PCs that simulate circuit behaviour rather than actually get the students to build (and potentially blow up) there designs. Too often modelling doesn't deal with real world issues such as decoupling requirements, noisy signals, and the fact that you can't get a 22.587ohm resistor.

There is a real skill in knowing how to build a system in stages so that when things don't work first time, you've got a debugging plan that lets you gain visibility where its needed. Simulation gives you a false sense of security because you can see everything and you don't have to face the real-world visibility limitations.

Personally, I think hybrid solutions based around rapid prototyping techniques give you the best of all worlds. You still get the chance to build your design using pre-tested hardware and component blocks, but you run it using real hardware rather than as a simulation. And with the price of many development kits getting so cheap, there's no reason why students can't do their 'labs' at home. In my view, we should be teaching our students to fail fast and fail cheap (http://drmarty.blogspot.com/2009/03/fail-fast-fail-chep.html)!

Sign in to Reply



Please sign in to post comment

Navigate to related information

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
Featured Job On
Scroll for More Jobs