When You Need Foresight!

By paul ~ August 15th, 2009. Filed under: Best Practices, RAMS, Systems Engr..

Quite often the question is posed about where and how Foresight can best be used to address modeling and simulation requirements.  So what are the qualifications of a good fit for Foresight (the tool) and the Resource Aware Modeling and Simulation (RAMS) methodology, given current competencies?  Here are the key characteristics of a good fit:

Highly Constrained Design:

A cell phone has a very high level of required functionality (many functionality points), high performance (speed, such as that required by streaming multimedia), low power consumption (and associated low power dissipation) and aggressive product development cycle. A satellite payload requires very low weight, small volume, low power, high resistance to damage in harsh environments (space and launch), it has to work right the first time and for a long time with minimal intervention, and it should be upgradeable while in service. These requirements create highly constrained problems for the designer as they pull the design in different directions.

Some level of concurrency or parallelism:

If the problem is easily serializable, then the need for good, simulation-based analysis drops dramatically as static analysis methods can solve the problem. Parallelism brings with it significant complexity in the design process, and bad designs can be very hard to fix once they’ve made their way to implementation. Further, problems are difficult to detect until test, at which point they become expensive to fix. Simulation-based analysis provides a very “comfortable” way to explore the design space and verify the candidate design. These kinds of systems often stray a bit from the space traditionally called “embedded systems.” At the very least, they are forming the most upper tier in the embedded systems space. Let me give some examples. Automotive engine management is still very easily serializable and, although I’m using Foresight to do some design, it really isn’t necessary. However, automotive system design is much more complex because it encompasses the integration of engine management with transmission management, vehicle dynamics control and active suspension, braking system, in-car services, smart sensors, etc. all over a complex network. Questions arise such as “Is it better to have a powerful, multi-processor centralized system with relatively dumb sensors and human interface components, or smart sensors and human interface components in a highly distributed system? What requirements are placed on the network by each approach? How do decisions such as the selection of standards like the CAN Bus affect the design?” These questions can be very hard to answer without simulation-based analysis. Typically, the ECU would be called an embedded system, but what do you call the whole system (where the use of Foresight becomes much more obvious?) Note that the introduction of an RTOS, whether it be a true embedded RTOS like Integrity, or an adapted more general OS like Windows CE, or Linux often is a good signal that the embedded system has moved into Foresight territory. Just tuning the scheduler can be a tough task, even for a single processor system.

Either hard real-time requirements or specific performance requirements:

When people speak of performance, it is usually related to speed.  However, for the industry at large, speed is only one of many performance metrics. Many practitioners would lump everything from flight dynamics to power consumption into performance requirements.) This bullet could be considered a subset of the 1st bullet, but I think it’s really separate. One could have a highly constrained design where speed wasn’t an issue and the use of Foresight wouldn’t be nearly as obvious.

There are a couple of conclusions that can be reached from this.  Most implementation-oriented modeling approaches (with simulation) aren’t very helpful at the level Foresight excels, (e.g., the HDLs, Rhapsody, SystemC, SimuLink and MatLab.) These work great for circuit design and embedded system design, but when you raise the level of abstraction a bit and begin looking at the system as a whole, two things happen:

1) Typically, you’ve moved to a different group of engineers. They may be called “systems engineers” or “system architects” but they aren’t usually conversant with HDLs or UML.

2) The problem is much more front-end focused. The primary task is identifying and understanding the requirements and mapping them into a top-level system design or architecture. As the project progresses, the detailed design and implementation is handed off and the system engineer’s attention will shift to verification.

3) The design process is above the hardware/software distinction but the hardware/software “decision” as well as other functionality mappings will occur before this process step is “complete.”

This is the where Foresight plays. Our primary position in the design flow is to bridge the gap between requirements analysis and detailed design. Our inputs are system requirements, our outputs are a finished architecture specification that can be implemented with confidence, as well as a verification vehicle that can be used to assist in the verification of the final system. Foresight provides incredible value in this space. Ask any engineer working in this space what tools they use to accomplish this task and the answer will be “what tools?”  They primarily use DOORS for requirements organization, and a few may, with difficulty; apply MATLAB/Simulink or Rhapsody, but little else. As Mr. Spock (from Star Trek) might have said “We’re asking engineers to design sophisticated systems with bearskins and stone knives”.

The Systems Engineering discipline has become very broad in recent years as engineering techniques are being applied to everything from logistics and business processes to construction, and there is no doubt that Foresight can play an important role in these areas.

The problem facing Foresight is getting the message of the value provided to that fuzzily defined group of people called Systems Engineers who, unfortunately, often don’t even carry that title in their organizations.  While there are competitors in what is perceived to be Foresight space, no single one appears to be any better positioned than Foresight.

Comments are closed.