Ordered Validation Made Easy

Ordered validation

[Music] hey guys it your favorite liability Jessica here's another action-packed video on reliability test and validation topics this current video is an introduction to verification and validation how processes and products are verified and validated I hope you enjoyed this video and if you do don't forget to hit that like button and subscribe to my channel thanks for watching and let's get started in this video we will cover definitions for verification and validation and verification and validation process per the beaker let's cover verification and validation definitions so what is verification in general terms it means to confirm that an object statement event and so forth are accurate and valid or as intended or advertised through a process driven approach an engineering it means to confirm that component subsystem or systems meet the requirements and technical specifications in manufacturing it means to confirm the process and production equipment and production fixtures and so forth meet design requirements and engineering specifications let's go ahead and define validation out so what is validation in general terms it means to confirm that an object statement event and so forth is accurate or valid or as intended or advertised through an action driven approach an engineering means to confirm that a component subsystem or system meets the customers needs or requirements and manufacture it means to confirm that a process production equipment production fixture and so forth ensures that the assembly of the component subsystem or system meets the customers needs and requirements let's go ahead and cover the verification and validation process for a product or system development lifecycle pictured is the VM V or V curve this diagram provides the process of how to develop verify and validate a product based on customer needs or requirements the left hand of the curve is the design process while the right hand curve is the verification and validation process let's cover each step as shown in the example B curve the customer requirements are how the customer expects the part or system you are developing to operate in perform and have the features that they would like to have this is the parameters features and performance warranty etc that the customer requires or once for the product or system the next step is the system requirements this is the V curve portion where the engineering teams come up with a high level technical solution to meet the customer requirements some folks get confused and think that the customer requirements and system requirements are different terms for the same documentation deliverables however this is far from the truth and those terms are not interchangeable for example a customer requirement may state that a vehicle must go 0 to 60 in three seconds is this sufficient for fabricating a vehicle that goes 0 to 60 seconds nope there's a myriad of automotive subsystems that require a well thought-out technical solution to achieve this target for instance the service 60 and three seconds requirement will require integrated technical solutions that are require a multidisciplinary input collaboration and agreement in order to achieve the requirement that is not as simple as it may look everything from the horsepower and torque for the propulsion system of the vehicle to the weight aerodynamics chassis tire and wheel selection and so forth also safety considerations must be taken into account as well as you lighten your vehicle and make it lighter and lighter to achieve the customer requirement for zero to 60 at 30 seconds safety considerations such as crash safety and crash design becomes more and more complex and requiring well-thought-out technical solution once the system requirements and system architecture are defined an SF r or system functional review is performed to ensure that there is cross-functional agreement among engineering teams that the system requirements and system architecture meet the customers requirements the next step is this subsystem design this is where engineering groups responsible for a particular subsystem develop their technical solutions to meet the system level requirements a PDR or preliminary design review is then performed to look for issues with each part of the design thus far and to fix any technical issues before going deeper into detail in the design during the preliminary design reviews reliability verification and validation teams should be a part of the step in order to both acquire information to begin developing reliability verification and validation test clients along with providing input on any potential issues they may cause well by building durability targets not to be met the reliability verification and validation teams should also be part of the development of the de FEMA's for subsystem and system level as these will be used as inputs into what will need to be verified as part of the risk-based verification and validation process and will be translated into reliability verification or validation actions based on the type of failure mode the severity of the failure mode and the probability of occurrences the next step is the detailed level design this is where components are selected to meet the subsystem functional targets reliability engineering should be involved at the step as they will need to assess component reliability which should be supplied by the manufacturer or supplier of the part if data does not exist for any particular part because it's a new technology for example then they reliable engineering team will need to conduct their own reliable intestine as part of the development process this can be both tricky and time-consuming and typically the component will be integrated into the design before tests and analysis has been completed it will be a technical and program risk decision to move forward with a part or component as a reliability studies are performed in parallel after the detailed level design is completed a CDR or critical design review is performed this is the last chance to dive deep into the design and make sure there aren't any outstanding issues or Corrections that need to be made before spending time and money on purchasing and fabricating parts the next step is the execution step this is where the software is coded parts are fabricated or ordered from suppliers the suppliers are responsible typically we're running tests to validate that a physical hardware component meet requirements as the OEM or subsystem supplier additionally during the step things such as test fixtures and tests harnason are built to support the upcoming verification and validation tasks as we move on to the right-hand side of the beaker we will perform ATR or tests readiness review ATR is critical as it ensures that there aren't any outstanding issues and that nothing has been missed during the test plan by the verification validation and reliability teams this is where the validation planes procedures and test parameters are reviewed to ensure that all critical functions features and kiln usage environments are addressed the TR is important also because it is used to verify that a location has been selected for verification and validation activities the support equipment has been purchased or built and that parts such as test fixtures harnesses or software have been built or purchased and that nothing has been missed to prevent the program schedule from slipping notice I have separated a lower and upper part of the V into two sections which shows the verification steps followed by the validation steps the first is this subsystem integration and testing step this is where you take components or parts and integrate them together to make a subsystem that carries a certain function or provides certain features for the entire system this typically starts as bench testing and progresses into other types of testing such as temperature testing or vibration testing depend on the function of the system and the application environments of the overall system at the bench level verification engineers will verify that the subsystem meets the design requirements for instance for an electronic subsystem the verification engineer will tests to see if outputs or signals match up to their expected output in the system requirements document likewise a software engineer will test to make sure software components that they developed and tested operate as intended per these system requirements wouldn't integrate it into software modules next we will have the system integration and test this is where you take all of your some assemblies and put them together as your system this is another verification step where you verify your sub assemblies operate as a unified system that meets the requirements and features of your system requirements and architecture likewise on the software side you will take all of your software modules and put them together as a software system and ensure that they meet these software requirements or system requirements for your product or system typically this is done by driven predetermine system level corner cases that are developed and called test cases so you have integrated all of your software and hardware together and it is working as intended for the system requirements we're done here right no this is only part of the sequence that you'll perform or that the engineering teams will perform as part of the product development process functionality and featured verification and making sure your system operates under optimal conditions is only part of the design equation what if conditions are not optimal what if the user is abused on this use of the product well you won't design your product to cover every corner case that some idiot will try to do with your system or product you need to consider how the product is going to be used and how to optimize the product to ensure that it meets warranty or as advertised warranty numbers a reliability engineering teams job is to assess risk they will perform accelerated life tests and step stress and design margin tests in order to determine the expected life of the product at the target reliability and confidence level verification and validation engineer teams will test the system to different electrical environmental and mechanical environments to ensure that the system operates under different types of environments as listed in the system requirements document after verification activities have been completed which is a combination of simulation documentation checks dimensional checks and physical testing an svr should be performed SPR stands for system verification review this is where all the stakeholders for the program review all verification activities to make a decision to into a preliminary production phase or to decide to make change to the design if a risk assessment determines that customer requirements will not be met or if there are any weaknesses or shortcomings in these system design verify the design and the requirements should be an ongoing effort prior to the SPR but the SPR is used as a final sanity check before moving into purchasing more materials and spending money on hard to land for mass production depending on the program schedule however an svr may be performed prior to the completion of verification and testing activities and a risk call is made to start cutting hard to learn to prepare for mass production and to keep the system production program schedule on track next up is design validation this is where you run through hardware mechanical and software test plans that are tailored to the customers requirements if you had all the plants aligned at this point you have designed enough design margin into your product and covered enough function and feature corner cases to breeze through validation testing but this is the real world depending on how fast the program is moving and the experience level of the engineering team you will most likely run into issues such as minor software bugs hardware and mechanical issues however I have seen cases where hard tooling for some parts had to change components had to be switched to a different supplier and materials had to be added to brackets and other mechanical components even Maddon's holes had to be changed or moved and electrical harness and a mechanical piping had to be rerouted these issues actually happen a lot and can cost thousands and even millions of dollars and days weeks or even months of schedule slippage so be careful and observant and look for any issues during the verification phase with your design in parallel to design validation production validation checks and tests are performed by the production or manufacturing engineering teams to ensure that a system meets the customer's requirements and also satisfies the design requirements this can be an interesting phase sometimes as if there are build issues the process or technology selection for manufacture may be blamed but it could also be a design for manufacturability issue if you have engineering teams and production teams pointing fingers at each other or and prediction teams are having a finger-pointing contest you will be wasting a lot of time and money as both teams try to prove that how they are building or designing the system or product is correct for that specific application this is why it's important for manufacturing engineering and design engineering to communicate and work together throughout the entire product development process so that there are no issues during production validation one more thing I forgot to mention before we continue is the regulatory and compliance aspects of the product development lifecycle a compliance team should be involved throughout the entire design process to ensure that components selected and the system as a whole meet regulatory and compliance requirements for the target market or country in which the system or product are to be sold some of this is simply documentation while other parts are tested such as government mandated safety testing to ensure the product or system do not kill the intended customer next up is the production release depending on the industry this can vary but it is a final review checklist to make sure all the I's are dotted and T's are crossed and that all reports data and requirements have been met for production once your system or product has exited the production release gate it is ready to be mass-produced and shipped to your customer well it may seem like engineering and manufacturing engineers jobs are done here maintaining the highest level of quality and reliability is an ongoing process checks and tests must be put in place as part of an ongoing and quality and reliability effort so sure the product or system maintains the target customer requirements for the life of a program and after mass production release and that's it folks some key takeaways from this video are communicate don't work in silos and don't be that person or team that keeps issues under rap until the 11th hour all different disciplines and teams should have an open to a form of communication to ensure everyone is on the same page and in agreement don't wait until formal meetings to talk to other teams to prevent slowdowns or added cost to the program all teams at a company are moving towards the same goal of making a world-class system or product for their customers so don't play politics or only communicate within your particular team plan out your verification and validation activities using a risk base approach what this means is understand your product or production risks by utilizing two famous and fathima's to determine areas of the design and production process that need to be focused upon that were determined to be of the highest risk priorities thank you for watching this video if you have any questions or comments or need help with verification and validation feel free to reach out to me at one of the links below I hope you enjoyed this video and if you did don't forget to hit that like button and subscribe to my channel thanks for watching and enjoy the rest of your day [Music] [Applause] [Applause] you