Sign In
Forgot Password?
Sign In | | Create Account

All present and correct.

When engineers design products – and electrical systems on transportation platforms are no exception – the process inevitably involves checking. Checking the elements of the design are all present and correct.

You may be testing the systems behave to anticipated norms. You may be looking back to the requirements, the specifications, looking over the shoulder to where the design work began, and seeking reassurance you are following the path you are sure is the right one. No wandering off course. You do this because you are committed to quality of outcome, and want to reach production with a robust, appropriate solution. You want the finished article’s function guaranteed – and the performance of the item as manufactured to be flawless. To reduce and hopefully eliminate errors you model, simulate and analyze.

The practice of virtualization and automation in software systems, like Capital encourages a systematic approach to these reviews and checkpoints.  This is undoubtedly good and enables you to do more work in less time, because the Design Rule adherence health-checks (like DRC’s) are reported swiftly in Capital Integrator or Capital Harness XC or Capital SimStress  – in fact wherever your design may take you. The model or models are tested, trialled and you get feedback in a matter of seconds, minutes at the most for things which formerly took hours or days.

Through my colleague John Low who is based in Seattle  I recently gained an insight into a distinction which is not rigidly observed in the way this “check and proceed or warn” functionality is manifested in the Capital Software. However this distinction is sometimes important to our Capital Customers – as individual engineers and the way they think and work and the value they put into the real world.  John has a wealth of experience in Mil-Aero Capital deployments.

The distinction is between Validation and Verification. It is the difference to answering the questions “am I building the right thing?”  – validation  which can be followed by “am I building the thing corectly?”  – verification. That’s a fairly subtle difference, and your inclination may be to say, let’s not split hairs. Let’s just look that the circuit or the harness or whatever is built right?

However, the point of this distinction is that you get made aware something can be constructed properly, perfect quality, but it turns out to be useless, inappropriate – invalid.  A harness module which never gets placed on a customer chosen harness.

Why are we bothered about these things? Because committment to manufacturing with a mistake or waste is expensive.

I will let John’s words free on my blog post – I will qutoe from an email he sent me.

“I use validation to indicate to what extent the “system” will meet the customer’s needs or requirements. Verification indicates that at each step of the design evolution, is it engineered well, is it free of design errors, etc.. So verification will ensure whatever is designed/built is high quality but it doesn’t ensure that it’s what the customer wants – that is validation.

Let’s say that the customer wants an electrical lawn mower that runs on 110VAC. Validation ensures that what is designed is electric, light and portable, runs on the right voltage, etc., etc.. Even though a gas-powered lawn mower will cut grass, it’s not what the spec says. So, we’re designing an electric lawn mower. Verification during design will now ensure I’ve picked the right parts that will run on the voltage I need to run at, ensure that the parts I pick will not burn out, ensures that the wires I select will meet the peak current load I will have, etc., etc..

In summary: Am I building (designing, etc.) the right thing? Yep, it’s an electric lawn mower for 110VAC. Am I building it right? Yep, because I’m doing virtual prototyping to ensure my design decisions are correct at each step of the design process.

 Maybe another way to look at this is Validate has more of capturing requirements and ensuring they are addressed.  Verification has to do with ensuring the best engineering decisions have been made to implement the requirements. “

In the Capital world we intermingle these two concepts – Validation and Verification. Validation can be at field or object level (this is a Ground device so therefor the software in this place at this stage will do x instead of y)  – Verification is exemplified perhaps best by the ground-breaking opportunities to simulate electrically using Capital Datasets the electrical behaviors of the subsystems’ physical manifestations as-designed.

Here are a couple of additional to explore the distinction in pictures.

The validity of signal mapping in Capital Integrator or Capital Insight is guaranteed to be true to the Capital Library device footprint definition. Providing you follow a set methodology.

Validation and correct by construction data results

Validation and correct by construction data

The next example shows the Verification of some option & harness family definition data consumed/analyzed in Capital Level Manager. As this data moves towards manufacture you don’t want a chance of a misbuild.

Is a valid data set more than plausible. Can what's modeled be built successfully?

Unentwining Verification and Validation gives insight into the processes Capital customers historically have used to insure their product quality. This helps to understand why design steps grew at customers into the way they are. Inevitably when customers adopt Capital they find opportunities for much more than they previously imagined they could accomplish with checks.  And you can extend with the Capital API too.

Manufacturing Verification, Design Validation, Capital, Capital Insight, Automotive Electrical and Electronic Systems Design, Design Rule Constraints, Design Rules, Capital Integrator, Data Validation

More Blog Posts

About Paul Johnston

Paul JohnstonI help Mentor Graphics customers to be successful, accomplish a more rapid return on investment. My professonal focus is on the Capital product line. Customers need a good technical and commercial understanding when making software system purchasing and adopting decisions and in addressing issues through to best resolution. I am one of the team of experts Mentor employs to support the Capital worldwide. I was born just outside of Manchester England, am now resident in the metro Detroit area of Michigan USA. I have worked for Mentor Graphics for more than 15 years. Visit Paul Johnston's Blog

More Posts by Paul Johnston


No one has commented yet on this post. Be the first to comment below.

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)


Online Chat