Validation و Verification چیست؟ تفاوت صحه‌گذاری و تصدیق در صنعت خودرو

در یک پروژه مهندسی ممکن است محصول دقیقاً مطابق نقشه‌ها، مشخصات فنی و الزامات طراحی ساخته شده باشد، اما در استفاده واقعی آن چیزی نباشد که مشتری یا پروژه به آن نیاز دارد. حالت برعکس هم ممکن است اتفاق بیفتد: یک نمونه در چند آزمایش اولیه عملکرد قابل قبولی نشان دهد، اما وقتی آن را با الزامات طراحی مقایسه می‌کنیم، متوجه شویم بخشی از مشخصات تعریف‌شده را برآورده نکرده است. همین تفاوت، ما را به دو مفهوم مهم در توسعه محصول می‌رساند: Verification و Validation.

این دو اصطلاح در پروژه‌های خودرویی زیاد استفاده می‌شوند و گاهی هر دو به‌سادگی «تأیید محصول» یا «آزمون محصول» ترجمه می‌شوند؛ در حالی که هدف یکسانی ندارند. Verification به‌طور کلی بررسی می‌کند که خروجی یک مرحله یا محصول با الزامات و مشخصاتی که برای آن تعریف شده‌اند مطابقت دارد یا خیر، در حالی که Validation به این می‌پردازد که محصول یا راه‌حل نهایی برای کاربرد و نیاز موردنظر مناسب است یا خیر. تفاوت شاید در یک جمله ساده به نظر برسد، اما در یک پروژه واقعی خودرو یا قطعه، تشخیص درست این دو بر نحوه تعریف الزامات، برنامه‌ریزی آزمون، ساخت نمونه و تصمیم‌گیری درباره آماده بودن محصول اثر می‌گذارد.

Verification چیست؟

Verification را می‌توان فرآیند بررسی انطباق خروجی با الزامات مشخص‌شده دانست. به زبان ساده، در Verification می‌خواهیم بدانیم چیزی که طراحی یا ساخته‌ایم، همان چیزی است که در Requirement، مشخصات فنی، نقشه یا سایر مدارک مهندسی تعریف کرده بودیم یا خیر.

فرض کنید تیم طراحی برای یک قطعه مجموعه‌ای از مشخصات تعریف کرده است: ابعاد باید در محدوده مشخصی باشند، ماده باید ویژگی‌های معینی داشته باشد، قطعه باید بار تعریف‌شده‌ای را تحمل کند و محل‌های اتصال نیز باید مطابق نقشه باشند. فعالیت‌های Verification بررسی می‌کنند که خروجی طراحی یا محصول ساخته‌شده با این الزامات مطابقت دارد یا نه. این بررسی بسته به ماهیت Requirement می‌تواند از طریق محاسبات مهندسی، تحلیل، بازبینی طراحی، بازرسی، اندازه‌گیری یا آزمون انجام شود.

بنابراین Verification الزاماً به معنی انجام یک آزمون فیزیکی نیست. اگر یک Requirement را بتوان از طریق بررسی نقشه، محاسبه یا تحلیل معتبر بررسی کرد، ممکن است همان روش برای Verification آن الزام مناسب باشد. نکته اصلی، وجود یک الزام مشخص و شواهدی برای نشان دادن انطباق خروجی با آن الزام است.

Validation چیست؟

Validation سؤال متفاوتی مطرح می‌کند: آیا محصول برای کاربرد موردنظر و نیاز واقعی که برای آن توسعه داده شده مناسب است؟ در اینجا صرفاً تطبیق محصول با یک نقشه یا Specification کافی نیست؛ باید بررسی شود محصول در شرایطی که قرار است مورد استفاده قرار گیرد، نیاز و عملکرد مورد انتظار را برآورده می‌کند یا خیر.

این تفاوت در صنعت خودرو اهمیت زیادی دارد، زیرا یک خودرو یا قطعه در نهایت در یک محیط واقعی و در تعامل با سایر سیستم‌ها کار می‌کند. ممکن است یک قطعه تمام ابعاد تعریف‌شده در نقشه را داشته باشد و الزامات فنی مشخص‌شده را نیز پاس کند، اما هنگام نصب روی خودرو، در شرایط کاری واقعی یا در تعامل با اجزای دیگر مشکلی ایجاد شود که در بررسی‌های اولیه دیده نشده بود. Validation تلاش می‌کند چنین فاصله‌ای میان «آنچه طراحی کرده‌ایم» و «آنچه واقعاً برای کاربرد موردنظر نیاز داریم» را شناسایی کند.

به همین دلیل، Validation معمولاً به شرایط استفاده موردنظر نزدیک‌تر است و می‌تواند شامل آزمون محصول، ارزیابی عملکرد در سطح سیستم یا خودرو، استفاده از نمونه‌های نزدیک به تولید و بررسی محصول در شرایط تعریف‌شده برای کاربرد نهایی باشد. نوع فعالیت Validation به محصول، مرحله توسعه، ریسک‌ها و الزامات پروژه بستگی دارد و برای همه پروژه‌ها یک نسخه ثابت وجود ندارد.

تفاوت Validation و Verification در چیست؟

یکی از معروف‌ترین توضیح‌ها برای تفاوت این دو مفهوم این است که Verification می‌پرسد «آیا محصول را درست ساخته‌ایم؟» و Validation می‌پرسد «آیا محصول درست را ساخته‌ایم؟». این عبارت برای به خاطر سپردن تفاوت مفید است، اما برای یک پروژه مهندسی کافی نیست. در عمل باید بدانیم هر Requirement چگونه و در چه مرحله‌ای اثبات می‌شود و چه شواهدی برای پذیرش محصول نیاز داریم.

مهم است که این جدول به‌عنوان یک مرزبندی مطلق تفسیر نشود. در یک پروژه واقعی ممکن است یک آزمون هم شواهدی برای Verification فراهم کند و هم بخشی از برنامه Validation باشد؛ چیزی که ماهیت فعالیت را مشخص می‌کند هدف ارزیابی و Requirement موردنظر است، نه صرفاً اینکه از دستگاه آزمون استفاده شده یا محصول روی خودرو نصب شده است.

یک مثال خودرویی؛ توسعه صندلی خودرو

فرض کنیم یک صندلی جدید برای خودرو در حال توسعه است. تیم مهندسی برای این صندلی مجموعه‌ای از Requirements تعریف کرده است: ابعاد و نقاط اتصال باید مطابق Package خودرو باشند، مکانیزم‌های تنظیم باید محدوده حرکتی مشخصی داشته باشند، ساختار صندلی باید الزامات مقاومتی تعیین‌شده را برآورده کند و محصول باید با فضای کابین و سایر اجزای خودرو سازگار باشد. در مراحل Verification، مهندسان می‌توانند نقشه‌ها را بررسی کنند، ابعاد نمونه را اندازه بگیرند، تحلیل سازه انجام دهند و برای Requirementsی که نیازمند آزمون هستند، آزمون‌های مناسب را اجرا کنند.

در ادامه پروژه، مسئله فقط این نیست که هر ویژگی به‌صورت جداگانه با Specification خود مطابقت داشته باشد. صندلی باید در خودرو نصب شود، با موقعیت راننده یا سرنشین، کمربند، فضای کابین و سایر اجزا تعامل مناسبی داشته باشد و در شرایط استفاده تعریف‌شده عملکرد مورد انتظار را ارائه کند. اینجا نگاه Validation پررنگ‌تر می‌شود؛ یعنی ارزیابی اینکه محصول توسعه‌یافته در سطحی نزدیک‌تر به کاربرد واقعی، نیازهایی را که برای آن تعریف شده برآورده می‌کند یا خیر.

این مثال یک نکته مهم دیگر را هم نشان می‌دهد: در توسعه یک محصول خودرویی، الزامات قانونی و استانداردی نیز می‌توانند بخشی از Requirements پروژه باشند. برای مثال، در حوزه استحکام صندلی و پشت‌سری، مقرراتی مانند UN R17 مطرح هستند و آزمون‌های مربوط به آن‌ها می‌توانند شواهد لازم برای بررسی انطباق با Requirement استانداردی را فراهم کنند. برای آشنایی با این آزمون می‌توانید صفحه آزمون استحکام صندلی خودرو – ECE R17 در وب‌سایت تات را مشاهده کنید.

آیا Testing همان Verification یا Validation است؟

خیر. Testing یا آزمون یک روش برای تولید شواهد و اطلاعات است و بسته به هدف پروژه می‌تواند در Verification، Validation یا سایر فعالیت‌های مهندسی مورد استفاده قرار گیرد. یکی از اشتباهات رایج این است که هر آزمونی را Validation بنامیم یا تصور کنیم اگر محصولی آزمون شده، فرآیند Validation آن نیز کامل شده است.

فرض کنید Requirement مشخص کرده است یک مجموعه باید نیروی معینی را طبق یک روش استاندارد تحمل کند. اجرای آزمون می‌تواند برای Verification همین Requirement استفاده شود. در موقعیت دیگری، ممکن است یک نمونه نزدیک به تولید تحت مجموعه‌ای از شرایط نماینده کاربرد نهایی آزمون شود تا مناسب بودن محصول برای استفاده موردنظر ارزیابی شود؛ در این حالت آزمون می‌تواند بخشی از Validation باشد. بنابراین نوع دستگاه یا حتی نام آزمون تعیین نمی‌کند که فعالیت Verification است یا Validation؛ هدفی که آزمون برای پاسخ دادن به آن طراحی شده تعیین‌کننده است.

همین موضوع اهمیت برنامه‌ریزی آزمون را نشان می‌دهد. اگر تیم پروژه نداند هر آزمون قرار است کدام Requirement یا ریسک را پوشش دهد، ممکن است تعداد زیادی آزمون انجام شود بدون اینکه شواهد لازم برای تصمیم‌گیری نهایی درباره محصول به‌صورت منظم ایجاد شده باشد.

Verification و Validation از چه زمانی شروع می‌شوند؟

یکی از اشتباهات پرهزینه این است که V&V را فعالیتی متعلق به پایان پروژه بدانیم؛ یعنی ابتدا طراحی را تمام کنیم، نمونه بسازیم و سپس ببینیم چه آزمون‌هایی لازم است. در یک فرآیند توسعه منظم، برنامه‌ریزی Verification و Validation باید هم‌زمان با شکل‌گیری Requirements آغاز شود. وقتی یک Requirement تعریف می‌شود، بهتر است همان زمان مشخص شود چگونه قرار است انطباق با آن اثبات شود، چه شواهدی لازم است و در چه مرحله‌ای این ارزیابی انجام خواهد شد.

این رویکرد یک مزیت مهم دارد: تیم پروژه پیش از رسیدن به نمونه نهایی می‌داند به چه نمونه‌هایی، تجهیزات، آزمون‌ها و زمان‌بندی‌هایی نیاز خواهد داشت. اگر یک آزمون به نمونه خاص، Fixture، تجهیزات اندازه‌گیری یا زمان رزرو آزمایشگاه نیاز داشته باشد، شناسایی آن در پایان پروژه می‌تواند برنامه توسعه را به تأخیر بیندازد. از طرف دیگر، بعضی مشکلات را می‌توان در مراحل تحلیل یا نمونه‌های اولیه شناسایی کرد و لازم نیست برای کشف آن‌ها تا نمونه نهایی منتظر ماند.

Design Verification و Design Validation چیست؟

وقتی اصطلاح‌های Design Verification و Design Validation استفاده می‌شوند، تمرکز مشخصاً روی طراحی محصول قرار می‌گیرد. Design Verification بررسی می‌کند که خروجی‌های طراحی، الزامات ورودی طراحی را برآورده کرده‌اند یا خیر. به عبارت دیگر، آیا آنچه تیم مهندسی طراحی کرده با Requirementsی که برای طراحی تعریف شده بودند مطابقت دارد؟

Design Validation از زاویه دیگری به طراحی نگاه می‌کند و بررسی می‌کند محصول حاصل از طراحی برای نیازها و کاربرد موردنظر مناسب است یا خیر. برای انجام Validation معتبر معمولاً باید شرایط ارزیابی تا حد مناسب نماینده کاربرد موردنظر باشند و محصول یا نمونه‌ای که ارزیابی می‌شود نیز متناسب با هدف Validation انتخاب شود. در صنعت خودرو، این موضوع می‌تواند به معنی استفاده از نمونه‌هایی با سطح بلوغ مشخص، نصب قطعه روی خودرو یا سیستم مرتبط و اجرای سناریوهایی باشد که شرایط واقعی یا تعریف‌شده کاربرد را نمایندگی می‌کنند.

DV و PV آیا همان Verification و Validation هستند؟

اصطلاح‌های DV و PV در صنعت خودرو بسیار رایج‌اند و معمولاً به Design Verification و Production Validation یا اصطلاحات نزدیک به آن‌ها در فرآیندهای توسعه سازمان‌ها اشاره می‌کنند. اما بهتر است DV/PV را بدون توجه به فرآیند توسعه و تعریف هر خودروساز یا سازمان، به‌صورت مکانیکی معادل Verification/Validation ندانیم.

در بسیاری از پروژه‌ها، DV روی نمونه‌هایی انجام می‌شود که برای ارزیابی طراحی ساخته شده‌اند و هدف آن شناسایی ضعف‌های طراحی پیش از رسیدن به تولید است. PV معمولاً در مرحله‌ای نزدیک‌تر به تولید و روی نمونه‌هایی انجام می‌شود که محصول، قطعات و فرآیند ساخت آن‌ها نماینده وضعیت تولیدی هستند. با این حال، تعریف دقیق Gateها، سطح بلوغ نمونه، آزمون‌های موردنیاز و معیارهای پذیرش می‌تواند میان خودروسازان و فرآیندهای توسعه متفاوت باشد. به همین دلیل، در یک پروژه واقعی باید ابتدا تعریف DV و PV در فرآیند همان پروژه مشخص شود و بعد برنامه آزمون بر اساس آن شکل بگیرد.

این موضوع ظرفیت یک مقاله مستقل را دارد، زیرا تفاوت نمونه‌های Prototype، DV و PV، زمان انجام آزمون‌ها و تصمیم‌هایی که در هر Gate گرفته می‌شوند جزئیات زیادی دارند و ترکیب همه آن‌ها با بحث اصلی Validation و Verification فقط باعث سنگین شدن این مقاله خواهد شد.

DVP&R چیست و چه ارتباطی با V&V دارد؟

در پروژه‌های خودرویی ممکن است با اصطلاح DVP&R یا Design Verification Plan and Report روبه‌رو شوید. این سند به‌طور کلی کمک می‌کند فعالیت‌های لازم برای Verification طراحی به‌صورت ساختاریافته برنامه‌ریزی و نتایج آن‌ها ثبت شوند. بسته به فرآیند سازمان، DVP&R می‌تواند شامل Requirement یا ویژگی مورد ارزیابی، روش Verification، استاندارد یا Procedure مربوط، تعداد و نوع نمونه، شرایط آزمون، معیار پذیرش، زمان انجام و در نهایت نتیجه باشد.

ارزش DVP&R فقط در داشتن یک جدول از آزمون‌ها نیست. یک DVP&R مناسب باید نشان دهد چرا هر آزمون انجام می‌شود و چه Requirement یا ریسکی را پوشش می‌دهد. اگر یک آزمون در برنامه وجود داشته باشد اما مشخص نباشد نتیجه آن برای تأیید کدام الزام استفاده می‌شود، ارتباط میان Requirements و شواهد Verification ضعیف خواهد بود. از طرف دیگر، اگر Requirement مهمی وجود داشته باشد که هیچ روش Verification برای آن تعریف نشده، پروژه با یک شکاف در برنامه ارزیابی روبه‌رو است.

Test Plan چه ارتباطی با Verification و Validation دارد؟

Test Plan یا برنامه آزمون یکی از ابزارهای مهم برای تبدیل الزامات مهندسی به فعالیت‌های اجرایی است. یک برنامه آزمون مناسب باید مشخص کند چه چیزی قرار است آزمون شود، هدف آزمون چیست، چه نمونه‌ای موردنیاز است، آزمون بر اساس چه استاندارد یا روشی انجام می‌شود، شرایط آزمون چیست، چه داده‌هایی باید ثبت شوند و معیار پذیرش چگونه تعریف شده است. در پروژه‌های پیچیده‌تر، زمان‌بندی نمونه‌ها، وابستگی میان آزمون‌ها و وضعیت تجهیزات نیز اهمیت پیدا می‌کند.

اما Test Plan زمانی بیشترین ارزش را دارد که به Requirements و برنامه V&V متصل باشد. اگر فهرستی از آزمون‌ها صرفاً بر اساس تجربه پروژه قبلی کپی شود، ممکن است با طراحی، ریسک‌ها یا کاربرد محصول جدید کاملاً منطبق نباشد. به همین دلیل، برنامه‌ریزی آزمون باید از شناخت محصول و الزامات آن شروع شود، نه از انتخاب دستگاه آزمایشگاه. این همان نقطه‌ای است که خدمات مهندسی و برنامه‌ریزی آزمون می‌تواند پیش از ورود محصول به مرحله آزمون رسمی ارزش ایجاد کند.

اگر طراحی محصول تغییر کند، آیا آزمون‌ها باید تکرار شوند؟

پاسخ همیشه «بله» یا «خیر» نیست. وقتی پس از Verification یا Validation تغییری در محصول ایجاد می‌شود، ابتدا باید اثر تغییر بررسی شود. ممکن است یک تغییر کوچک هیچ اثری بر Requirement یا عملکردی که قبلاً ارزیابی شده نداشته باشد، اما تغییر دیگری—even اگر از نظر ظاهری کوچک باشد—مسیر انتقال بار، ماده، هندسه، نرم‌افزار، عملکرد سیستم یا شرایط استفاده را تغییر دهد و بخشی از نتایج قبلی را دیگر قابل اتکا نکند.

به همین دلیل، مدیریت تغییر بخشی جدی از V&V است. پس از هر تغییر باید مشخص شود کدام Requirements تحت تأثیر قرار گرفته‌اند، چه شواهدی از ارزیابی قبلی همچنان معتبر است و چه فعالیت‌هایی نیاز به تکرار یا تکمیل دارند. تصمیم برای Re-Test نیز بهتر است بر اساس تحلیل فنی اثر تغییر و الزامات پروژه گرفته شود، نه صرفاً بر اساس اینکه «این قطعه قبلاً یک‌بار آزمون شده است».

نقش آزمایشگاه در فرآیند Verification و Validation چیست؟

آزمایشگاه می‌تواند بخش مهمی از شواهد موردنیاز V&V را از طریق اجرای آزمون‌های تعریف‌شده فراهم کند، اما آزمایشگاه به‌تنهایی جایگزین فرآیند Verification و Validation محصول نیست. مسئولیت تعریف Requirements، تعیین کاربرد موردنظر، مدیریت ریسک‌ها و تصمیم‌گیری درباره کفایت برنامه V&V در سطح پروژه قرار دارد؛ آزمایشگاه آزمون را بر اساس روش، استاندارد و شرایط تعریف‌شده انجام می‌دهد و نتایج آن می‌تواند یکی از ورودی‌های تصمیم‌گیری مهندسی باشد.

این تفکیک به‌خصوص در آزمون‌های استاندارد اهمیت دارد. موفقیت در یک آزمون مشخص نشان می‌دهد نمونه تحت شرایط آن آزمون چه عملکردی داشته و آیا معیارهای مربوط را برآورده کرده است؛ اما نباید نتیجه یک آزمون منفرد را بدون بررسی دامنه آن به معنی Validation کامل کل محصول در تمام کاربردها دانست. هر آزمون پاسخ یک سؤال مشخص را می‌دهد و برنامه V&V باید مجموعه سؤال‌های لازم برای تصمیم‌گیری درباره محصول را پوشش دهد.

خدمات مهندسی و صحه‌گذاری محصول چه کمکی به پروژه می‌کنند؟

در بسیاری از پروژه‌ها، چالش اصلی خود اجرای آزمون نیست؛ مسئله این است که چه چیزی باید آزمون شود، در چه مرحله‌ای، با چه نمونه‌ای و بر اساس چه Requirement یا استانداردی. اگر این موارد دیر مشخص شوند، ممکن است نمونه نامناسب ساخته شود، یک آزمون ضروری در برنامه دیده نشود یا پس از تغییر طراحی بخشی از آزمون‌ها نیاز به تکرار پیدا کنند.

واحد خدمات مهندسی و مشاوره تات در حوزه‌هایی مانند بررسی الزامات فنی و استانداردی، برنامه‌ریزی آزمون و پشتیبانی فرآیند صحه‌گذاری محصول فعالیت می‌کند. هدف چنین خدماتی جایگزینی تصمیم مهندسی سازنده یا تضمین قبولی در آزمون نیست؛ بلکه کمک به ساختارمند شدن مسیر پروژه، شناسایی الزامات و برنامه‌ریزی فعالیت‌های لازم پیش از اجرای آزمون است.

اگر پروژه‌ای در مرحله توسعه دارید و هنوز الزامات، آزمون‌های موردنیاز یا مسیر ارزیابی آن به‌طور کامل مشخص نشده است، امکان ثبت درخواست و ارائه اطلاعات اولیه پروژه از طریق سامانه ارتباط و مراقبت از مشتری تات نیز وجود دارد تا درخواست برای بررسی اولیه در اختیار کارشناسان مربوط قرار گیرد.

Verification و Validation مکمل یکدیگرند، نه جایگزین یکدیگر

Verification و Validation دو سؤال متفاوت درباره محصول مطرح می‌کنند و به همین دلیل یکی نمی‌تواند جای دیگری را بگیرد. ممکن است محصولی تمام Specifications تعریف‌شده را برآورده کند اما برای کاربرد موردنظر مناسب نباشد؛ همان‌طور که عملکرد ظاهراً مناسب یک نمونه در چند شرایط محدود نیز ثابت نمی‌کند تمام Requirements طراحی آن Verification شده‌اند. یک فرآیند توسعه قابل اتکا باید هر دو زاویه را ببیند: آیا خروجی با الزامات تعریف‌شده منطبق است و آیا محصول نهایی نیاز و کاربرد موردنظر را برآورده می‌کند؟

در صنعت خودرو، پاسخ به این دو سؤال معمولاً حاصل یک فعالیت واحد نیست. Requirement Management، تحلیل و بازبینی طراحی، نمونه‌سازی، اندازه‌گیری، آزمون، ارزیابی در سطح سیستم یا خودرو، مدیریت تغییر و مستندسازی نتایج در کنار یکدیگر قرار می‌گیرند تا شواهد لازم برای تصمیم‌گیری ایجاد شوند. هرچه این مسیر زودتر و منظم‌تر در پروژه تعریف شود، احتمال اینکه مشکلات اصلی تنها در مراحل پایانی توسعه یا هنگام آزمون رسمی آشکار شوند کمتر خواهد بود.