برمجيات إلكترونيات الطيران

عادةً ما تُصمَّم نماذج أولية أو تُحاكى المشاريع التي تتضمن تفاعلاً بشرياً مكثفاً. ويُحتفظ عادةً بتسجيل الفيديو، ولكن يُستغنى عن النموذج الأولي فوراً بعد الاختبار، وإلا فقد يعتقد كبار المديرين والعملاء أن النظام مكتمل. ومن الأهداف الرئيسية تحديد مشكلات التفاعل البشري التي قد تؤثر على السلامة وسهولة الاستخدام.

عادةً ما تخضع إلكترونيات الطيران الحساسة للسلامة لتحليل المخاطر . في المراحل الأولى من المشروع، يكون لدى المصمم فكرة عامة على الأقل عن أجزائه الرئيسية. يقوم المهندس بعد ذلك بدراسة كل جزء من أجزاء المخطط الانسيابي، وينظر في المشاكل المحتملة التي قد تحدث فيه، وكيف تؤثر على النظام ككل. ثم يتم تقدير شدة المخاطر واحتمالية حدوثها. بعد ذلك، تتحول هذه المشاكل إلى متطلبات تُدرج في مواصفات التصميم.

عادة ما تتضمن المشاريع المتعلقة بأمن التشفير العسكري تحليلًا أمنيًا، باستخدام أساليب مشابهة جدًا لتحليل المخاطر.

بمجرد اكتمال المواصفات الهندسية، يمكن البدء في كتابة دليل الصيانة. يُعدّ دليل الصيانة ضروريًا لإجراء الإصلاحات، وبالطبع، إذا تعذّر إصلاح النظام، فلن يكون آمنًا.

تتضمن معظم المعايير مستويات متعددة. قد يُرفق بمواصفات منتج ذي مستوى أمان منخفض، مثل وحدة الترفيه على متن الطائرة (تلفزيون طائر)، مخططات وإجراءات التركيب والضبط. أما نظام الملاحة أو الطيار الآلي أو المحرك، فقد يتضمن آلاف الصفحات من الإجراءات والفحوصات وتعليمات التركيب. تُسلّم الوثائق الآن (منذ عام ٢٠٠٣) بشكل روتيني على أقراص مدمجة (CD-ROM)، بتنسيقات قياسية تشمل النصوص والصور.

من أغرب متطلبات التوثيق أن معظم العقود التجارية تشترط ضمان توفر وثائق النظام بشكل دائم. والطريقة التجارية المعتادة لتقديم هذا الضمان هي إنشاء وتمويل مؤسسة أو صندوق استئماني صغير. يتولى هذا الصندوق إدارة صندوق بريد ويودع نسخًا (عادةً على رقاقات فائقة الرقة ) في مكان آمن، مثل مساحة مستأجرة في مكتبة جامعة (تُدار كمجموعة خاصة)، أو (وهو أمر نادر الآن) مدفونة في كهف أو موقع صحراوي. ^{[ 4 ]}

تتشابه هذه النماذج عادةً مع تلك الموجودة في نماذج تطوير البرمجيات الأخرى . ويكمن الاختلاف الجوهري في أن تتبع المتطلبات يتم عادةً كما هو موضح أعلاه. في المشاريع الكبيرة، يُعد تتبع المتطلبات مهمة ضخمة ومكلفة للغاية، مما يستلزم استخدام برامج حاسوبية ضخمة ومكلفة لإدارتها.

يُكتب الكود، ثم يُراجع عادةً من قِبل مبرمج (أو مجموعة من المبرمجين، عادةً بشكل مستقل) لم يكتبه في الأصل (وهذا شرط قانوني آخر). كما تُجري منظمات متخصصة عادةً مراجعات للكود باستخدام قائمة مرجعية للأخطاء المحتملة. وعند اكتشاف نوع جديد من الأخطاء، يُضاف إلى القائمة المرجعية، ويُصلح في جميع أجزاء الكود.

غالبًا ما يُفحص الكود بواسطة برامج متخصصة لتحليل صحته ( تحليل الكود الثابت )، مثل برنامج SPARK examiner للغة SPARK (وهي مجموعة فرعية من لغة البرمجة Ada) أو برنامج lint لعائلة لغات البرمجة C (وخاصةً C). تتحقق المترجمات أو برامج الفحص المتخصصة مثل "lint" من توافق أنواع البيانات مع العمليات عليها، كما تُستخدم هذه الأدوات بانتظام لفرض استخدام صارم لمجموعات فرعية صحيحة من لغات البرمجة وأساليب البرمجة. وهناك مجموعة أخرى من البرامج تقيس مؤشرات أداء البرمجيات ، للبحث عن أجزاء الكود التي يُحتمل أن تحتوي على أخطاء. تُصلح جميع المشاكل، أو على الأقل تُفهم وتُراجع بدقة.

بعض البرامج، مثل المرشحات الرقمية وواجهات المستخدم الرسومية وأنظمة الملاحة بالقصور الذاتي ، مفهومة جيداً لدرجة أنه تم تطوير أدوات برمجية لكتابة هذه البرامج. في هذه الحالات، يتم وضع المواصفات ويتم إنتاج برامج موثوقة تلقائياً.

يُكتب كود اختبار الوحدة لتنفيذ كل تعليمة من تعليمات الكود مرة واحدة على الأقل للحصول على تغطية كاملة للكود . غالبًا ما تُستخدم أداة تغطية للتحقق من تنفيذ كل تعليمة، ثم تُوثَّق تغطية الاختبار أيضًا لأسباب قانونية.

يُعدّ هذا الاختبار من بين أقوى الاختبارات، إذ يُلزم بمراجعة دقيقة لمنطق البرنامج، ويكشف معظم أخطاء البرمجة والمترجم وبعض أخطاء التصميم. تقوم بعض المؤسسات بكتابة اختبارات الوحدة قبل كتابة الكود، مستخدمةً تصميم البرنامج كمواصفات للوحدة. يُنفّذ كود اختبار الوحدة، وتُصلح جميع المشاكل.

بمجرد توفر أجزاء من الشفرة البرمجية، تُضاف إلى هيكل الشفرة الأساسي، وتُختبر في مكانها للتأكد من عمل كل واجهة. عادةً ما تُستكمل الاختبارات المدمجة للإلكترونيات أولاً، قبل البدء باختبارات التشغيل الأولي واختبارات انبعاثات الراديو للإلكترونيات.

بعد ذلك، يتم دمج أهم ميزات البرنامج. في هذه المرحلة، من المفيد غالبًا للمطورين أن تتوفر لديهم طريقة لتشغيل أجزاء صغيرة ومحددة من التعليمات البرمجية، ربما من خلال نظام قوائم بسيط.

يحاول بعض مديري البرامج ترتيب عملية التكامل هذه بحيث يصبح النظام قابلاً للتسليم في أي تاريخ لاحق بعد تحقيق مستوى أدنى من الوظائف، مع زيادة عدد الميزات بمرور الوقت.

في هذه الأثناء، يبدأ مهندسو الاختبار عادةً بتجميع جهاز الاختبار، وإصدار اختبارات أولية لاستخدامها من قبل مهندسي البرمجيات. وفي مرحلة ما، تغطي الاختبارات جميع وظائف المواصفات الهندسية. عند هذه المرحلة، يبدأ اختبار وحدة إلكترونيات الطيران بأكملها. والهدف من اختبار القبول هو إثبات أن الوحدة آمنة وموثوقة في التشغيل.

يُعدّ الاختبار الأول للبرنامج، وأحد أصعب الاختبارات التي يُمكن إجراؤها ضمن جدول زمني ضيق، اختبارًا واقعيًا لانبعاثات الراديو الصادرة من الوحدة. وعادةً ما يجب البدء بهذا الاختبار في وقت مبكر من المشروع لضمان وجود وقت كافٍ لإجراء أي تعديلات ضرورية على تصميم الإلكترونيات. كما يخضع البرنامج لتحليل تغطية هيكلية، حيث تُجرى الاختبارات ويتم جمع بيانات تغطية الكود وتحليلها.

تُنتج كل خطوة مُخرَجًا، إما وثيقةً أو برنامجًا أو تقرير اختبار. وعندما يجتاز البرنامج جميع اختباراته (أو ما يكفي منها ليتم بيعه بأمان)، تُجمَع هذه الاختبارات في تقرير اعتماد، قد يصل عدد صفحاته إلى آلاف الصفحات. ثم يُقرر الممثل الهندسي المُعيَّن، الذي سعى جاهدًا لإنجاز المشروع، ما إذا كانت النتيجة مقبولة. إذا كانت كذلك، يُوقِّع عليها، وبذلك يُعتمد برنامج إلكترونيات الطيران.