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.
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.
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.