معايير التصديق على البرمجيات DO-178B و DO-178C تعمل كدليل لإنتاج أنظمة جوية صالحة للطيران. تم نشر DO-178B (اعتبارات البرمجيات في أنظمة الطائرات ومعدات التصديق) لأول مرة في عام 1992، وكانت الوثيقة الرئيسية التي تم أخذها في الاعتبار للحصول على التصديق من السلطات مثل EASA (وكالة السلامة الجوية الأوروبية) و FAA (إدارة الطيران الفيدرالية) لأنظمة الطيران التجارية المبنية على البرمجيات. ومع ذلك، اعترفت لوائح الطيران الفيدرالية بـ DO-178C كطريقة لإثبات التوافق مع معايير الصلاحية للطيران في عام 2013. لمزيد من المعلومات العامة حول معايير DO-178B و DO-178C، يمكنك قراءة هذا المقال.
يجب أن تلبي معايير DO-178B أو DO-178C من خلال وثائق مثل:
- PSAC (Plan for Software Aspects of Certification)
- SDP (Software Development Plan)
- SVP (Software Verification Plan)
- SCMP (Software Configuration Management Plan)
- SQAP (Software Quality Assurance Plan)
- SAS (Software Accomplishment Summary)
هذه ليست الوثائق الوحيدة المطلوبة لتلبية معايير DO-178B و DO-178C. هناك عدد كبير من الوثائق الأخرى لتعزيز الصلاحية للطيران. يمكنك التحقق من هذه الوثائق وشراؤها من هنا.
وثائق DO178
وثيقة PSAC
PSAC (Plan for Software Aspects of Certification) وثيقة يصف المعايير والعمليات والبروتوكولات والمنهجيات اللازمة التي يجب اتباعها، كما أنه يبرز بيانات دورة الحياة. وبالتالي، يمكن تحقيق أهداف وثائق DO-178. كما يحدد PSAC جدول تطوير البرمجيات ونظرة عامة على النظام. يستخدم كل من السلطة المعتمدة والمتقدم بهذه الوثيقة. يجب إنتاج PSAC في عملية التخطيط الأولية للبرمجيات والحصول على موافقة السلطة. للتحقق من وثيقة PSAC الخاصة بنا، يرجى النقر هنا.
وثيقة SDP
SDP (Software Development Plan) وثيقة إلى التحقق مما إذا كانت المعلومات الضرورية مثل. وثيقة SDP هي جزء أساسي من فترة تخطيط البرمجيات. للتحقق من وثيقة SDP الخاصة بنا، يرجى النقر هنا
وثيقة SVP
SVP (Software Verification Plan) تحدد الحالات والتغطيات الضرورية للاختبار، والإجراءات، والبروتوكولات، والتحقق من المتطلبات، والتحقق من شيفرة المصدر مع التحكم المناسب بالإصدارات. SVP هي أيضًا عنصر أساسي في عملية التخطيط. للتحقق من وثيقة SVP الخاصة بنا، يرجى النقر هنا.
وثيقة SCMP
SCMP (Software Configuration Management Plan) وثيقة هي جانب آخر مهم من فترة التخطيط. خلال عملية تطوير البرمجيات، غالبًا ما يكون الحال أن الخطة الأولية تتغير. تساعد SCMP في اكتشاف هذه التغييرات والتحكم فيها وصيانتها وتتبعها. يتم تطبيقها طوال عملية تطوير البرمجيات. تهدف SCMP إلى تقليل الأخطاء وزيادة الإنتاجية. يجب على أعضاء الفريق بذل الجهد للإبلاغ عن التغييرات وإخطارها. للتحقق من وثيقة SCMP الخاصة بنا، يرجى النقر هنا.
وثيقة SQAP
SQAP (Software Quality Assurance Plan) وثيقة تتضمن الأدوات والطرق والتقنيات المستخدمة لضمان أن المنتج أو الخدمة يلبي المواصفات المحددة في SRS (مواصفات متطلبات البرمجيات). تشرح SQAP كيف سيتم إجراء أنشطة ضمان جودة البرمجيات في المشروع. يحدد فريق SQA المعالم الرئيسية ويقيم جودة المشروع عند كل معلم. يتم إجراء SQA طوال دورة حياة البرمجيات. للتحقق من وثيقة SQAP الخاصة بنا، يرجى النقر هنا.
وثيقة SAS
SAS (Software Accomplishment Summary) وثيقة تلخص كل خطوة من خطوات مكونات البرمجيات خلال التطوير والتحقق. يجب أن تتضمن SAS ملخصًا لنتائج أدوات التحقق من المؤهلات. يجب إخطار الـ FAA بـ SAS. يسمح ذلك للسلطة المعتمدة بالتحقق من نتائج بيانات التحقق ويعمل كدليل على حالة تأهيل الأداة. للتحقق من وثيقة SAS الخاصة بنا، يرجى النقر هنا.
معايير ARP4754 ومعايير DO178
ARP4754 تعني “ممارسة موصى بها في مجال الطيران ARP4754A لإرشادات تطوير الطائرات المدنية وأنظمتها”. توفر معايير ARP4754 إرشادات لأنظمة الطائرات الكاملة بينما تستخدم معايير DO178 لبرمجيات الطيران. كلا المعيارين مقبولان من قبل السلطات مثل FAA و EASA.
تم تطوير ARP4754 ونشرها من قبل SAE (جمعية مهندسي السيارات) في عام 1996. في عام 2010 نشرت SAE ARP4754A والتي تعني إرشادات لتطوير الطائرات المدنية وأنظمتها. توسع ARP4754A فكرة ضمان التصميم للاستخدام على مستويات الطائرة والنظام، كما توحد استخدام مصطلح ضمان التطوير. تم الاعتراف بـ ARP4754 من قبل FAA في نوفمبر 2011.
تغطي ARP4754 دورة تطوير الطائرة بأكملها من المتطلبات إلى الاندماج والتحقق. توفر ARP4754 تجريدًا للطائرة والنظام والعنصر. بالنسبة لتصميم العنصر، تشير ARP4754 بشكل صريح إلى DO-178 و DO-254. تركز ARP4754 على تقييم السلامة طوال عمليات مختلفة مثل التطوير والتصميم والتحقق. ومع ذلك، يجب الإشارة إلى أن ARP4754 لا تتضمن نطاقًا محددًا لتطوير البرمجيات أو الأجهزة الإلكترونية، أنشطة السلامة أثناء الخدمة، وتطوير هيكل الطائرة.
مراحل التصميم
Preliminary Design Review (PDR)
التصميم التمهيدي هو مرحلة أساسية في عملية تطوير البرمجيات. خلال التصميم التمهيدي، يتم تحديد المتطلبات عالية المستوى وحالات الاستخدام لبناء هيكلية النظام. يمكن استخدام وثائق للواجهة، وقاعدة البيانات، والهيكلية ورسومات بيانية لعلاقات المكونات في التصميم. سيقدم التصميم التمهيدي تصورًا بصريًا للنظام في بداية المشروع استنادًا إلى هذه المدخلات. كما يضع التصميم التمهيدي الأساس لمراحل التصميم التفصيلية التالية. يمكن اعتباره كخريطة تصميم.
تنهي مراجعة التصميم التمهيدي (PDR) مرحلة التصميم التمهيدي للمشروع. للمضي قدمًا في التصميم التفصيلي، يجب أن تقدم PRD ضمانًا كافيًا. الغرض من PDR هو التأكد من اكتمال التصميم التمهيدي وهيكلية النظام الأساسية، وأن هناك ثقة تقنية بأن المتطلبات يمكن تلبيتها ضمن الميزانية والجدول الزمني.
Critical Design Review (CDR)
تنهي مراجعة التصميم النقدي (CDR) مرحلة التصميم النقدي للمشروع. يتم تقديم التصاميم النهائية مع CDR من خلال التحليل الشامل والمحاكاة والمخططات وشيفرة البرمجيات وبيانات الاختبار. تضمن CDR أن النظام يمكن أن يتقدم إلى الاختبار والإنتاج. كما أنها تعبر عن أن المتطلبات المذكورة يمكن تلبيتها ضمن الميزانية والجدول الزمني. توفر الرسومات والمواصفات الشاملة التي تنشأ خط أساس أولي للمنتج، مع خط أساس نهائي. يجب أن تكون CDR شاملة ومنهجية.
Final Design Phase
توفر مرحلة التصميم النهائي رسومات معمارية وهندسية مفصلة لكل مكون في المشروع. بالنسبة لبعض المشاريع، قد يكون من الضروري إنشاء تقرير تصميم نهائي. يجب حل المشكلات التصميمية المكتشفة قبل الانتهاء من مرحلة التصميم النهائي. يجب أن تقدم الرسومات والتقرير تفاصيل كافية للسماح بتقديرات دقيقة نسبيًا لتكاليف البناء والتشغيل، وكذلك توقيت البناء. يجب أن يتضمن التقرير النهائي للتصميم جدولًا زمنيًا محدثًا، وتقديرات التكاليف، والمواصفات. كما يجب الموافقة على أن المشروع اقتصادياً قابل للتطبيق. أي تغيير خلال مرحلة التصميم النهائي أكثر تكلفة مقارنة بالمراحل الأخرى. وبالتالي، يجب تنفيذها بعناية فائقة.
SOI (Stages of Involvement)
تُجرى تقييمات مراحل الاشتراك (SOI) من قبل سلطات الطيران في البلدان ذات الصلة في مراحل مختلفة من المشروع مثل التخطيط والتطوير والتحقق لتقييم مطابقة المشاريع لمعايير DO-178B. في الحالات المثالية، من المخطط إجراء مراجعات SOI إجمالاً أربعة.
التقييم الأولي، وهو SOI الأول، يتضمن مرحلة التخطيط لدراسات التصديق على المشروع. تركز مراجعة SOI الثانية على مراحل تطوير المشروع. بدءًا من تطوير متطلبات البرمجيات الراقية، يتساءل عما إذا كان التصميم ومتطلبات البرمجيات المنخفضة المستوى وشيفرة المصدر تم إنتاجها وفقًا لـ DO178B. تركز مراجعة SOI الثالثة على مراحل التحقق. ليس فقط أنشطة الاختبار، ولكن جميع الأنشطة التي تُجرى لأغراض التحقق يتم فحصها. أما SOI الرابع، فهو التقييم الختامي الذي يُجرى بالقرب من نهاية المشروع، ويتساءل عما إذا كان هناك نشاط متبقي مفتوح وما إذا كانت قد ظهرت مشكلة جديدة منذ التقييمات السابقة.
توقع DO-178B من المنتجات البرمجية المنتجة خلال مرحلة التخطيط هو الاتفاق على مجموعة قواعد مشتركة بين السلطة والشركة المنتجة والالتزام بهذه المجموعة من القواعد طوال المشروع. بمعنى آخر، عند كتابة الخطط والمعايير، لا تحدد الشركة عملياتها الخاصة فحسب، بل تكتب أيضًا القواعد لكيفية تقييم السلطة لنفسها طوال عملية التصديق.
المؤلف: Can Önal ([email protected])
Mor Teknoloji
