Initial members are:

SRB Consulting, Inc. —Specializes in training, consulting and seminars on the Fibre Channel Protocol and Foresight modeling. Fibre Channel (a gigabit-speed network technology) has quickly become the standard for enterprise-level network storage, and is growing rapidly in the Mil-Aero market as an avionics and weapons systems data bus.  SRB uses Foresight for Fibre Channel system design and performance modeling.  www.srbconsulting.com

SavanSys Solutions, LLC—Provider of electronics manufacturing supply chain cost modeling, an activity based cost model that enables fabrication and assembly in a virtual prototype of supplier factories.  SavanSys provides solutions for supply chain management, new technology introduction and cost/risk reduction. SavanSys Solutions is able to apply Foresight Resource Aware Modeling and Simulation (RAMS) to the manufacturing and supply chain management disciplines.  www.savansys.com

Prime Solutions Group, Inc.— Systems Engineering and integration experts providing  value-added contributions to program acquisition, planning, integration, test and deployment of advanced aerospace systems.  PSG specializes in the application of current commercial strategies and methodologies that enhance system acquisitions and introduce cost, technical, and programmatic efficiencies into all aspects of the project life cycle turning good projects into great projects focused on customer needs. PSG and Foresight have teamed for SBIR proposal submissions.  www.psg-inc.net

If you have an interest in becoming an affiliate member, please contact Gerry Allen at gallen@foresight-mands.com.  We look forward to hearing from you.

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.

Stockage Breadth

Stockage breadth determinations are often made by a simple rule of thumb using the frequency of demands for an item as a model.  For example, to add an item to the ASL at the US Army retail level, 9 recurring demands within 360 days are required.  Given an estimated order-ship-time (OST) of 20 days this policy guarantees that 180 days of stock outs before an item can be added to the ASL.  The loss of critical combat equipment for this length of time significantly reduces combat readiness.  In a merchandising operation, 180 days of waiting for an item can result in significant loss of profit and loss of customers.  Moreover, the demand quantity is not considered in current models using frequency of demand stockage rules.  A better approach would be to use the demand frequency and the demand quantity in an algorithm that considers the cost associated with not having an item in inventory. This algorithm is explained below.

Simulation models with algorithms that determine stockage breadth based on a decision rule of not stocking (lost profit) versus the cost of stocking (holding an item in inventory in anticipation of a customer demand) will optimize overall profit (military readiness), customer satisfaction and cost savings.  Quite simply, the rule is:  If the cost of not stocking is greater than the cost of stocking, add the item to the inventory, otherwise do not stock the item. In this manner, the benefits derived from stocking an item will be in proportion to the related inventory carrying costs. Aside from using empirical customer demand for determining what to stock, merchandisers, for example, can benefit from simulation based on changing fashion trends, changing technology, advertising campaigns, and marketing forecasts.

Stockage Depth

Stockage depth determination of how much to stock (order quantity, Q) and when to re-order (reorder point, RP) is also subject to simulation and sensitivity analysis which can identify significant cost saving in inventory investment.

Q determinations can be simulated using Economic Order Quantity (EOQ) using various stochastic demand distributions such as Poisson and constraints (e.g. budgetary or spatial), in order to determine optimum customer satisfaction.

The RP is the sum of the Order-Ship-Time (OST) and the Safety Level (SL).  OST is the forecasted demand quantity for an item between the interval of re-ordering and receipt of an item in inventory, often referred to customer demand during lead time.  The SL is an added quantity to allow for fluctuations in demand (standard deviation) during lead time and fluctuations in the delivery time (also a standard deviation): a condition of dual uncertainty.

The components Q, OST and RP are called the Requisitioning Objective (RO) in the Army model.  In an asset triggered re-order system or point-of-sale system such as at Home Depot, an order is generated whenever the Net Assets are less than or equal to the RO.  Net assets are comprised of the Balance on Hand (BOH) plus Due In (DI) - stocked items on order plus Due Out (DO) - back orders awaiting stock replenishment. The only difference for a merchandising operation in this model is the absence of customer requests awaiting stock replenishment (DO).  Either the item is on hand or else there is a loss sale.  No back order is generated.

Sensitivity analysis simulations of each of the RO components can be accomplished to optimize customer satisfaction and inventory investment.  Moreover, with the capacity of computing power currently available, virtual sensitivity adjustments can be made in inventory investment in real time.

Foresight Systems M & S has the software know-how to make virtual inventory optimization a reality.  Some examples include:

• Transportation costs skyrocket as the fuel prices increase, triggering an increase in ordering costs which, in real time, will adjust upward the economic order quantity (EOQ).  A virtual optimization of “cost to order” and “cost to hold” will result in overall lower inventory costs.
• Day-to-day changes in the cost of not stocking an item can be implemented without delay.
• Limited time quantity-discount offers from vendors and resulting changes in Q, OST and SL can be evaluated in near real time.
• Changes in the stochastic demand model used for forecasting can be accommodated in real time.
• “The inventory investment interest rate decreases thus lower holding costs which recalculates a higher Q that minimizes total costs of ordering and holding.

Foresight sensitivity simulation and virtual inventory optimization is the way of the future for most retail, asset triggered reordering systems.   We are actively pursuing the application of Foresight’s proven systems modeling tools and methodologies to inventory and supply-chain management and will soon be bringing tailored, innovative solutions to market.  If you have interest in such applications, please contact us. If you have questions or comments relevant to this post, we invite you to register and comment.

(Note, We did not address the Just-In-Time (JIT) inventory model .  JIT is not applicable to conditions of uncertain demand and fluctuations in demand during lead time and fluctuations in the length of the delivery time.  JIT is best used for manufacturing operations where demand can be more accurately forecasted for planned production.  Also, with increasing fuel prices and transportation costs, JIT may not be the most cost effective solution.)

Walter Bawell brings significant depth of experience in logistics to the Foresight management team.

Scottsdale, AZ — March 19, 2009 — Foresight Systems M&S (Foresight), a developer of advanced visualization software for the design of complex highly constrained systems is pleased to announce that Walter Bawell has joined the Foresight management team as Director, European Region.  Walt has over 30 years of logistics engineering experience and is recognized as one of the foremost Army logistics thinkers.  Walt developed and modeled algorithms for repair parts stocking decisions which reduced inventory levels while improving world wide availability of stocked items.  He chaired and led the Department of Defense (DoD) procurement and implementation of bar code technology, Logistical Marking and Reading System (LOGMARS), returning a savings of $110 million within 3 years.  As Commander of a Corps Materiel Management Center in Germany he developed a software asset visibility system yielding $24 million in cost avoidance charges.

Serving at NATO headquarters in Brussels and the US Embassy in Germany, Walt was instrumental in the development of the NATO communications software development center.  As Chief of the Joint Programs Section, Office of Defense Cooperation, US Embassy, he directed multi-million dollar cooperative defense research programs and  was the project manager for the $2.3B Patriot/Roland agreement signed by the US and German secretaries of Defense.  Walt advised the US Ambassador in Germany on defense cooperation issues and made recommendations to congressional staff for enabling legislation to support international joint ventures.  As the personal representative of the Commander-In-Chief, United States Army Europe, to the German ministries of Defense, Finance and Transportation, Walt has developed deep international contacts in key policy making positions.

As national president of the American German Business Club (AGBC), Walt worked closely with the US Department of Commerce and the US Embassy in Germany to expand and strengthen mid-level business and commercial ties between US and German companies.

He has published numerous articles on logistics for the Army Logistician, Handling and Shipping trade journal, Armed Forces Comptroller and the Defense Institute for Security Assistance Management, of which he is a graduate.  He is co-author of the text book Management of Business Logistics used by the Pennsylvania State University.

Walt is a Certified Professional Logistician, has a BS in Accounting and Management and a MS in Business Logistics from Pennsylvania State University and is a graduate of the Army War College and the Command and General Staff College.

About Foresight:
Foresight Systems M&S meets the challenge of building complex highly constrained systems quickly and efficiently.  The company’s military grade Resource Aware Modeling and Simulation (RAMS) software works from system requirements to produce a detailed design specification that can be implemented with confidence.  These powerful analysis tools allow engineers to look ahead and optimize implementation decisions during system design.  Anticipating system tradeoffs early allows designers to manage complexity, provides additional flexibility, compresses product cycles and minimizes execution risk.

The company’s customers represent the leading edge of the communications technology, aerospace and defense industries.  Representative users include:  Bell Northern Research, Boeing, General Dynamics, Hewlett-Packard, L-3 Communications, Lockheed Martin, Motorola, Nokia, Raytheon, Texas Instruments and United Technologies.

For further information on Foresight, please visit our website. For direct inquires, please contact:

Gerry Allen
Foresight Systems M&S
480-551-6477

fs_marketing@foresight-mands.com
http://www.foresight-mands.com
http://www.foresight-mands.com/blog

In order to be successful, the systems engineering team must take ownership of the customer’s requirements from the outset.  Not only must they receive and document the requirements, but they must also invest themselves in the discovery and elaboration of the requirements.  A team that simply accepts a requirements spec from a customer at face value with a few clarifying questions is off on the wrong foot already.  Perform a formal requirements analysis with the customer and other stakeholders even on projects that seem to have pretty clearly defined requirements.  It may not be necessary to do this in the pre-award stage, but it should be included in the proposal and undertaken after award.  Although expensive, this is a win-win for the customer and contractor.  It helps ensure that the system requirements are clearly understood, elaborated to a greater level of detail, and properly documented.  During this activity, initial verification planning can take place as well.  To this end, ask questions like “What does the customer expect or demand for verification for each requirement (in terms of Analysis, Inspection, Demonstration or Test.) ” and “Where are periodic Technical Performance Measurements (TPMs) required?”

Once the requirements analysis is complete, the software engineering team ‘turns around” and faces the engineering teams.  They will continue to interface with the customer and negotiate requirements, but now they are representing the customer and the system requirements to the engineering teams.  The emphasis becomes ensuring that the requirements are adequately understood by the design teams and traceable through the design processes.  A Model-Based Systems Engineering (MBSE) or Model Driven Architecture (MDA) approach can significantly aid in this phase by facilitating a tight linkage between system components and the requirements they are intended to satisfy.  This was previously discussed in the blog article Why is Model Driven Systems Engineering So Important?  For instance, the Foresight modeling environment facilitates requirements traceability by directly linking entities in the model with requirements in a DOORS database.  (See the RQIF-DOORS interface.)

The MBSE approach further helps the systems engineer by enabling design verification by Analysis.  For complex systems and systems that are very expensive to demonstrate or test, Analysis is the preferred verification method until final test is possible.  Further, some performance metrics are so critical that they should be tracked throughout the design process as TPMs.  Models facilitate these activities by providing analyzable design artifacts.

It is never too soon to start verification planning.  As mentioned previously, initial verification planning should start during requirements analysis.  The systems engineering team should complete a preliminary verification plan as early as possible and get it to the quality assurance teams.  It is critical that test planning & specification occur as early as possible so that required testability features can be designed into the system rather than being added ad-hoc later.  Again, an MBSE approach can help this process.  Wherever possible, verification activities (AIDT) should be specified against the model and prototypes as well as the delivered system.

Where subcontractors are involved, it is critical that the entire process survive across the integrator/subcontractor boundary.  Without this, the system engineering team’s job becomes more like herding cats than sheep!  Requirements traceability, verification planning, modeling, and test planning should be as transparent and coherent as possible across the design teams.  The only places where this can be safely relaxed is at the COTS (or nearly COTS) components.  Otherwise, verification becomes a nightmare.

While the process described here is heavily front-loaded (an ounce of prevention…), the system engineer’s job isn’t done until that last requirement is checked off, with the customer.  It really is like shepherding, and the customer requires frequent (and honest) assurance that things are going as planned.  An MBSE strategy provides the systems engineer with a tool that can be used in each milestone review to communicate measurable progress against requirements that is compatible with the customer’s viewpoint.

(As a personal aside, please do not fall for an MBSE or MDA strategy that results in models that are not simulatable and/or otherwise analyzable!  If you can’t spec a test against the model, then that model has limited value.  It’s really just another kind of documentation.  For complex, multi-processor embedded systems, use Foresight as part of your MBSE solution!)

Systems engineering will probably never be for the faint-hearted.  However, there are some “best practices” that can help.  I’ve described a few from my experience here.  I’d love to hear your thoughts on the matter.

Having said this, our belief is that a proven model-based systems engineering tool with strong performance analysis capabilities, could be extended to other domains.   Supply chain management, manufacturing flow and business process are all complex systems and, therefore, lend themselves to Foresight’s Resource Aware Modeling and Simulation (RAMS). For example, the separation of a system’s functionality (e.g. the need to move items from point A to point B, warehouse materials and product, manufacture items, take orders, deliver, etc.) from the resources (trucks, scheduling, manufacturing facilities, people, warehouse space, etc.) Other industry segments with similar attributes and requirements include building architecture, training scenario simulation, environmental impact modeling, and any application that demands the ability to visualize and analyze multiple permutations and effects of a premise, or design, at the lowest risk and cost.

True, there are tools, particularly in logistics, that begin to address these problems but there is a real possibility that Foresight can bring added benefit. Paul, Foresight’s CTO, has done some preliminary work along these lines, particularly the brief on process which can be found http://www.foresightsystems-mands.com/bpm.html along with other papers addressing expanded application of the Foresight tool.

While we know possibilities exist, we are stymied by the fact that we don’t have the depth of knowledge and/or experience in these other application areas. All of which is to say that while we believe there are lucrative market opportunities, we need to find experienced practitioners with similar interests willing to partner, or invest, in the development of viable, marketable solutions.

We would be interested in hearing from any of you from a couple of perspectives. First, any comments or suggestions regarding your usage or consideration of Foresight as an enabling tool in any of these disciplines or any other application areas of interest. Secondly, your comments focused on any interest in extending our application and market reach through partnering efforts to mutually solve specific requirements or market opportunities you may foresee.

I became fascinated by mesh networking after being exposed to some of the challenges and approaches in the defense sector.  Since then, I’ve been following developments in this area with interest.  This is a field that is going to explode in coming years in the commercial sector.  The ability to cover a wide area with low power, limited range devices is incredibly useful and will result in some innovative applications.  There are a staggering number of enabling technologies emerging and these are going to require some sorting out.  Hopefully “survival of the fittest” will do the sorting!

Mr. Ewing’s article really impressed me on a couple of levels.  First, he describes an excellent, requirements-driven systems engineering approach in his discussion of how Synapse developed their SNAP protocol.  This is the kind of process, and resulting “genius”, that I really respect.  Secondly, their focus on platform independence is laudable.  Third is the innovative thinking demonstrated by their use of a lightweight, byte-compiled interpreted language (Python in this case) for the application programming environment.  And finally, the raw capability of the resulting protocol is impressive.  Kudos to the team, stellar performance.  I can’t wait to see how the market receives the Synapse solution.

Something Niall does not mention in his article is the role that virtual prototyping can play in getting your user interface design right.  If you’ve read the Digital Imaging With ARM and Voice Interactive Nav/Com case studies, you’ve seen some examples of how Foresight can be used to help.  In the former, Altia Design is used to prototype a digital camera interface.  In the latter the device is voice interactive and the UI behavior is entirely handled via audio.

The power of this approach comes from the fact that not only the placement and type of controls (or voice commands) can be visualized, but the behavior of the system can be accurately simulated.  This enables Human In the Loop simulations where a user can interact with the system in real-time.  Experiments with alternative interaction strategies, control placement, etc. can be rapidly performed in a virtual environment resulting in quick convergence on a graceful solution.  Mechanical prototypes can be linked to the simulation in the same way in order to evaluate a UI with mechanical controls.

For very complex systems with training requirements, the resulting virtual prototype can be used in the development of training materials and training delivery.  Foresight’s CoderC++ product makes it possible to compile simulations into stand-alone executables that can be easily (and freely) delivered for evaluation and training purposes.

Human-Machine Interface (HMI) design using virtual prototyping is really part of an overall model-based systems engineering flow and can be invaluable in flushing out all of those tiny little interaction requirements that are often overlooked.  Creating a user interface that meets the basic IO requirements is easy.  Creating a user interface that users coo over is an entirely different matter, and that’s what we really want to accomplish.

One of Brian’s most valuable contributions in the paper is a lucid discussion of the level of timing accuracy required for different development tasks.  Brian touches on this throughout the paper, but deals with it head-on in a section headed Accuracy and Timing.   He makes an important observation in this section:

So if hardware has not yet been implemented, how can we know the exact timing? The only thing that can be shown is that it meets the requirements. That is one of the purposes of a system level virtual prototype - to work out the timing necessary and other details of the architecture long before they are frozen. Thus timing is an artifact of implementation, and the lack of timing in the early stages of a project does not imply inaccuracy, just the degrees of freedom currently left in the design process.  (Emphasis mine.)

Well put!  One of the concerns that I have often heard expressed when discussing the usefulness of system-level modeling at high levels of abstraction is this issue of accuracy.  Since we know that, by its very nature, an abstraction cannot be accurate in an absolute sense, is it useful?  After all, systems fail because of timing problems in the nanoseconds, don’t they?

Yes, at some level, accuracy is important, but it is also expensive.  In the early stages of the design process, however, when we’re trying to settle on an architecture that will satisfy the system requirements, detailed accuracy is not so important.  And it is at this point that we can benefit from design at a higher level of abstraction to create a system more immune to timing error.

As I read Brian’s paper, I was struck with the fact that he makes a powerful argument for system-level modeling and simulation, even before you get to the kind of virtual prototyping enabled by the OVP technologies.  For complex designs, it is critical to explore the design space through a malleable high level model before you invest in detailed hardware design and start software development.  The hardware/software decision itself must be made carefully.  Software architecture and technology selection (ASIP vs. GP core, single processor vs. multiple processors, switched fabric vs. serial vs. parallel bus, etc.) should always be worked out before committing the kind of investment required to build a virtual prototype upon which to develop software.

High-level modeling tools, such as Foresight, enable the rapid prototyping and evaluation of architectures prior to committing to detailed design and implementation.  The resulting models are accurate enough to make excellent design optimization decisions and are quick and easy to use.  Because the broad-brush decisions have been made in the higher level model, less energy is wasted in exploring dead-ends with the more labor-intensive virtual platform model.

Please understand that I am not arguing against the use of virtual platform methods.  These developments are very exciting and definitely a valuable enabler.  My suggestion is simply to lift your eyes a bit higher still, reach for another rung, and see if additional benefit cannot be gained from an even higher level of abstraction.

The paper is an excellent survey of some of the major ESL methods in use. It makes a strong argument for the OVP World approach and offerings. In addition, Brian points out some of the key drivers in the SoC industry that should be leading to faster adoption of ESL methods. Not surprisingly, one of these drivers is the continuing growth in SoC complexity and, in particular, the number of multi-processor SoCs.

In the Abstract, Brian observes:

For many years, Electronic System Level (ESL) design and verification has been on the cusp of widespread adoption, but never seems to get there. Universities and companies claim to have the necessary breakthrough only to see the technology sit there for years or the company to hobble along without ever really becoming a success. Is this because ESL is failing to deliver on the promises or that the products are flawed? Is it because the preconceived notion of ESL is wrong?

I share Brian’s perplexity. We share a little bit of history, Brian and I. Back in ‘98, (wow, over a decade ago) we worked together on an ESL project that brought Mentor Graphics’ Seamless CVE tool together with Foresight to create a higher-level co-design solution. The result was pretty cool. You could build a high-level model of your system in Foresight, iron out the design issues and verify it. Then, when you had HDL and software, you could put them together in Seamless CVE and exercise the result from Foresight via co-simulation. The system-level model became the testbench for the implementation. We actually demonstrated this using the predecessor to the model described in the Digital Imaging with ARM whitepaper in the Mentor suite at the 2000 DAC.

The idea was well received, but the product wasn’t successful. I think we sold one seat of the combination. Nor were later developments that enabled Foresight co-simulation with HDL simulators successful. I have often wondered why…

Brian goes on to speculate that a key reason for the slow pace of ESL adoption is that, after about 10 years:

We have neither model interoperability nor independence between model and tool. Because of this, it is almost impossible to put together complete ESL flows today, and thus ESL adoption remains patchy at best, and often derided.

Maybe. While I think that interoperability will be a great enabler, I’m not sure that’s what the holdup has been. More fundamentally, I think that the commercial electronics design community does not adopt higher abstraction design approaches until they show an order of magnitude productivity improvement. For ESL (and above, where we sit) this has been difficult to prove and will likely always be difficult to prove conclusively. However, there comes a point, as Brian points out in the paper, where the sheer complexity of designs drives us to a higher level of abstraction. System-level modeling approaches have been used for years in the military/aerospace industries for this very reason. Perhaps SoC designs are now reaching this point.