Continuous Systems Validation - Progressive Design Representations

by Chad Jackson, President and Principal Analyst of Lifecycle Insights

I now have no doubt left in my mind: system simulation is now all the rage.

A few weeks ago, I hopped on the bandwagon to write on the topic. I published a post titled Systems Simulation: Far-off Future or Feasible Now? here at the NAFEMs blog. That post focused on how to build a simulation model that incorporates various digital and physical representations from different engineering disciplines. Its complicated stuff in its own right. In that post, I posed the question of whether we're close to reality or some future vision.

Reality, however, is actually far far more complicated. Some organizations actually don't want to just simulate a system's performance at a single point in time, but want to progressively check behavior and validate requirements continuously during the design cycle. In simulation-speak, that makes it a transient problem. Suddenly a seemingly complex challenge becomes an order of magnitude more complicated.

With this post, I'm starting a three part series that looks at the next level of complexity and ultimately what capabilities are needed by software solutions. Where do we start? It makes sense to kick things off by looking at reality right in the face. Let's examine how design representations progressively change over time by engineering discipline.

The Progression of Mechanical Designs

OK. So where does it all start for mechanical design? How do engineers represent their design? And how to do they assess performance? From my perspective, the progression of mechanical design looks something like the following.

• Concept Design
• Representations: 2D hand or digital sketches (not drawings)
• Assessments: Hand or digital calculations, dramatically simplified kinematic or beam FEA models
  
  
• Detailed Design
• Representations: 3D models in CAD software
• Assessments: Hand or digital calculations, directional or detailed simulation models
  
  
• Testing and Validation
• Representations: Prototype parts manufactured as one-offs or in small batches
• Assessments: Physical tests in environments representative of operating conditions

Now of course, this is still simplified. There are various shades of gray between each of these types of representations and assessments, but it will serve the purpose of this conversation. Now, let's take a look at electrical and electronic design.

The Progression of Board and Processor Design

Here, the engineers are designing boards as well as processors (ASICs, FPGAs, SoC, etc.) and have similar questions to answer. How are the designs represented? How are they assessed? Here's the progression for electronics.

• Concept Design
• Representations: Representations of the functional logic behind the electronics are 2D diagrams and layouts. This can also be represented by UML models and even programming code.
• Assessments: Simulations can be run testing the logic represented by the 2D diagrams and layouts. In some cases, this can even look like unit tests used for software code.
  
  
• Detailed Design
• Representations: 2D layouts and 3D assemblies are created for boards. Similar representations are created for processors.
• Assessments: Functional logic of the electronics are tested here again in simulations. But additional thermal-fluid coupled simulations are introduced here to validate thermal management issues.
  
  
• Testing and Validation
• Representations: Prototype boards are created. Prototype processors and manufactured.
• Assessments: Multiple tests are conducting that check both the functional logic and thermal cooling performance of these items.

Again, this is a simplified view of electronics design. However, it is representative of the progression from a very functional representation to the physical item that is prototyped and tested.

The Progression of Software and Controller Design

With software, there is no physical item to ultimately manufacture. Instead, you flash the software onto controller hardware, where it merges with the design of the electronics. However, the same questions are relevant here. How are the designs progressively represented? How is performance assessed?

• Concept Design
• Representations: Software design almost always starts with architecture. The functional logic of the software is often captured in logic diagrams, sometimes with UML models.
• Assessments: Much like electronics at this stage, simulations can be executed that tests the logic that exists in the diagrams and models.
  
  
• Combined Detailed Design / Testing and Validation
• Representations: Software is then planned, designed and coded. According to popular software development processes, code is compiled on a certain time schedule, often daily.
• Assessments: Even during early coding, tests can be performed that identify problems with software. This is done continuously throughout the development process. The idea is to reduce the number of outstanding issues to an acceptable level.

 

It interesting that in the software world, there really aren't separate phases of detailed design and testing. Testing occurs very early on and continues all the way through release of the finished compiled software. In this way, this concept of continuous systems validation is more familiar than it is to mechanical and electrical engineering organizations.

Summary and Questions

Why is this important?

Well, think about what continuous validation of a system's performance actually means in the context of progressive representations and assessments in each engineering discipline. That brings up all sorts of interesting implications, but we'll get into that detail in the next post.

For now, let's recap.

• Organizations are increasingly wanting to validation system's performance continuously during the development cycle.
• Design representations of mechanical, electrical and software aspects of a system progressively change during the development cycle.
• The way that engineers assess the performance of their designs also change and progress during the development cycle.
• Continuously assessing a system's performance, thereby, means leveraging different design representations and assessments during the development cycle.

Every organization is different. How do your designs progress? Any major representations I missed? Sound off and let us know your thoughts.

Take care. Talk soon. And thanks for reading.

View all blog posts