الشلالات مذهلة بطبيعتها ، لذلك ليس من المستغرب أن المهندسين مهووسون بها قليلاً. أوصى معيار DOD-STD-2167A القديم باستخدام نموذج الشلال ، واستندت خلفيتي الهندسية القديمة إلى نموذج بوابة البوابة ، والذي أعتقد أنه رتق مشابه لنموذج الشلال. من ناحية أخرى ، فإن أولئك الذين درسوا علوم الكمبيوتر في الجامعة ربما يعرفون أن نموذج الشلال هو بطريقة ما مضاد للنمط . أخبرنا أصدقاؤنا في برج العاج الأكاديمي لا ، لا ، رشيقةهو طريق النجاح ويبدو أن الصناعة أثبتت صحة هذا الادعاء.
لذا ، ما الذي يجب على المطور اختياره بين نموذج الشلال القديم و Agile الجديدة؟ هل تتغير المعادلة عندما يتعلق الأمر بتطوير الخوارزميات؟ أو بعض البرامج الأمنية الهامة؟
كالعادة في الحياة ، يكمن الجواب في مكان ما بينهما.
هجين ، لولبي ونمط V
التطوير الهجين هو الجواب الذي يجلس في الوسط. عندما لا يسمح نموذج الشلال بالعودة وتغيير المتطلبات ، فإن النموذج الهجين يفعل ذلك. وحيث تواجه Agile مشاكل في التصميم المسبق ، فإن التطوير الهجين يترك مجالًا لذلك. علاوة على ذلك ، يهدف التطوير الهجين إلى تقليل عدد العيوب في المنتج النهائي ، وهو ما ربما نريده عند تصميم الخوارزميات للتطبيقات الحساسة للأمان.
تبدو جيدة ، ولكن ما مدى فعاليتها؟
للإجابة على هذا السؤال ، نراهن على التنمية المختلطة أثناء العمل على خوارزمية توطين NDT.... التوطين هو جزء أساسي من أي كومة ذاتية القيادة تتجاوز التحكم التفاعلي النقي. إذا كنت لا تصدقني أو كنت غير معتاد على الأقلمة ، فإنني أوصي بشدة بإلقاء نظرة على بعض مستندات التصميم التي تم تطويرها من خلال هذه العملية.
إذن ما هو التطور الهجين باختصار؟ من وجهة نظري للهواة ، أود أن أقول إن هذا نموذج مثالي على شكل حرف V ، أو حلزوني . تقوم بالتخطيط والتصميم والتنفيذ والاختبار ، ثم تكرار العملية بأكملها استنادًا إلى الدروس المستفادة والمعرفة الجديدة التي اكتسبتها خلال تلك الفترة.
الاستخدام العملي
بشكل أكثر تحديدًا ، نحن ، مع مجموعة عمل NDT في Autoware .Auto ، أكملنا أول نزولنا أسفل الشلال الأيسر لنموذج V (أي جعلنا التكرار الأول خلال مرحلة التصميم) استعدادًا لـ Autoware Hackathon في لندن (التي تديرها Parkopedia !). تألفنا من خلال مرحلة التصميم من الخطوات التالية:
- مراجعة الأدبيات
- نظرة عامة على التطبيقات الحالية
- تصميم مكونات عالية المستوى وحالات الاستخدام والمتطلبات
- تحليل الخطأ
- تعريف المقاييس
- هندسة وتصميم API
يمكنك إلقاء نظرة على كل من المستندات الناتجة إذا كنت مهتمًا بشيء مشابه ، ولكن في بقية هذا المنشور سأحاول تقسيم بعضها ، وأشرح أيضًا ما سبب ذلك في كل مرحلة من هذه المراحل ولماذا.
مراجعة الأدبيات والتطبيقات الموجودة
الخطوة الأولى في أي مسعى لائق (وهي كيفية تصنيف تطبيق NDT) هي معرفة ما فعله الآخرون. البشر ، بعد كل شيء ، كائنات اجتماعية ، وكل إنجازاتنا تقف على أكتاف العمالقة.
بغض النظر عن التلميحات ، هناك مجالان مهمان يجب مراعاتهما عند النظر في "فن الماضي": الأدب الأكاديمي والإنجازات الوظيفية.
من المفيد دائمًا النظر إلى ما كان يعمل عليه طلاب الدراسات العليا الفقراء في خضم المجاعة. في أحسن الأحوال ، ستجد أن هناك خوارزمية ممتازة تمامًا يمكنك تنفيذها بدلاً من خوارزمية خاصة بك. في أسوأ الحالات ، ستكتسب فهمًا للحيز وتنوع الحلول (التي يمكن أن تساعد في هندسة المعلومات) ، وستتمكن أيضًا من التعرف على بعض الأسس النظرية للخوارزمية (وبالتالي أي الثوابت التي يجب أن تنتبه لها ).
من ناحية أخرى ، من المفيد بنفس القدر أن ننظر إلى ما يفعله الآخرون - بعد كل شيء ، من الأسهل دائمًا البدء في القيام بشيء ما باستخدام دليل البدء. لا يمكنك فقط استعارة أفكار معمارية جيدة مجانًا ، ولكن يمكنك أيضًا اكتشاف بعض التخمينات والحيل القذرة التي قد تحتاجها لجعل الخوارزمية تعمل بشكل عملي (وقد تتمكن حتى من دمجها بالكامل في الهندسة المعمارية الخاصة بك).
من مراجعتنا لأدبيات NDT ، قمنا بجمع المعلومات المفيدة التالية:
- تحتوي عائلة خوارزميات NDT على العديد من الاختلافات:
- P2D
- D2D
- Limited
- الدلالية - هناك الكثير من الحيل القذرة التي يمكن استخدامها لتحسين أداء الخوارزمية.
- عادةً ما تتم مقارنة NDT بـ ICP
- NDT أسرع قليلاً وأكثر موثوقية قليلاً.
- يعمل NDT بشكل موثوق (لديه معدل نجاح مرتفع) داخل منطقة محددة
لا يوجد شيء لا يصدق ، ولكن يمكن حفظ هذه المعلومات لاستخدامها لاحقًا ، سواء في التصميم أو التنفيذ.
وبالمثل ، من خلال نظرة عامة على عمليات التنفيذ الحالية ، لم نر فقط خطوات ملموسة ولكن أيضًا بعض استراتيجيات التهيئة المثيرة للاهتمام.
استخدام الحالات والمتطلبات والآليات
جزء لا يتجزأ من أي عملية تطوير تصميم أو خطة أولاً هو معالجة المشكلة التي تحاول حلها على مستوى عال. بالمعنى الواسع ، من وجهة نظر السلامة الوظيفية (التي أعترف أنني بعيدة عن خبير) ، فإن "النظرة الرفيعة المستوى للمشكلة" منظمة تقريبًا على النحو التالي:
- ما حالات الاستخدام التي تحاول حلها؟
- ما هي المتطلبات (أو القيود) لحل يفي بحالات الاستخدام المذكورة أعلاه؟
- ما هي الآليات التي تلبي المتطلبات المذكورة أعلاه؟
توفر العملية الموضحة أعلاه نظرة منضبطة رفيعة المستوى للمشكلة وتصبح تدريجياً أكثر تفصيلاً.
للحصول على فكرة عما قد يبدو عليه ذلك ، يمكنك إلقاء نظرة على وثيقة مشروع الأقلمة عالية المستوى التي قمنا بإعدادها معًا استعدادًا لتطوير NDT. إذا لم تكن في مزاج جيد للقراءة قبل النوم ، فتابع القراءة.
استخدم حالات
أنا أحب ثلاثة طرق التفكير لاستخدام الحالات (الانتباه ، أنا لست خبير سلامة وظيفية):
- ماذا يفترض بالمكون أن يفعل؟ (تذكر SOTIF !)
- ما هي الطرق التي يمكنني من خلالها إدخال الإدخال في مكون؟ (حالات استخدام المدخلات ، أحب أن أسميها منبعًا)
- ما هي طرق الحصول على الإخراج؟ (حالات استخدام عطلة نهاية الأسبوع أو من أعلى لأسفل)
- سؤال إضافي: في أي بنى نظام يمكن لهذا المكون أن يقيم؟
بعد تجميع كل ذلك ، توصلنا إلى ما يلي:
- يمكن لمعظم الخوارزميات استخدام الأقلمة ، ولكن في النهاية يمكن تقسيمها إلى نكهات تعمل محليًا وعالميًا.
- الخوارزميات المحلية تحتاج إلى الاستمرارية في تاريخ التحول.
- يمكن استخدام أي مستشعر تقريبًا كمصدر لبيانات التوطين.
- نحتاج إلى طريقة لتهيئة طرق التعريب وإصلاحها.
بصرف النظر عن حالات الاستخدام المختلفة التي يمكنك التفكير فيها ، أود أيضًا التفكير في بعض حالات الاستخدام الشائعة الصارمة جدًا. للقيام بذلك ، لدي خيار (أو مهمة) رحلة على الطرق الوعرة بدون طيار تمامًا ، مروراً بالعديد من الأنفاق مع حركة المرور في قافلة. هناك نوعان من الإزعاج مع حالة الاستخدام هذه مثل تراكم أخطاء قياس المسافات ، وأخطاء النقطة العائمة ، وتصحيحات التعريب ، وانقطاع الخدمة.
المتطلبات
الغرض من تطوير حالات الاستخدام ، بالإضافة إلى تعميم أي مشكلة تحاول حلها ، هو تحديد المتطلبات. لكي تحدث حالة استخدام (أو تكون راضية) ، ربما تكون هناك بعض العوامل التي يجب أن تتحقق أو ممكنة. بعبارة أخرى ، لكل حالة استخدام مجموعة محددة من المتطلبات.
في النهاية ، المتطلبات العامة لنظام الأقلمة ليست مخيفة إلى هذا الحد:
- توفير تحويلات للخوارزميات المحلية
- توفير تحويلات للخوارزميات العالمية
- توفير آلية لتهيئة خوارزميات التوطين النسبي
- تأكد من عدم امتداد التحويلات
- ضمان الامتثال REP105
من المرجح أن يقوم أخصائيو السلامة الوظيفية المؤهلون بصياغة العديد من المتطلبات. تكمن قيمة هذا العمل في حقيقة أننا صاغنا بوضوح متطلبات (أو قيود) معينة لتصميمنا ، والتي ، مثل الآليات ، ستفي بمتطلباتنا لتشغيل الخوارزمية.
الآليات
يجب أن تكون النتيجة النهائية لأي نوع من التحليل مجموعة عملية من الدروس أو المواد. إذا لم نتمكن من استخدام النتيجة (حتى نتيجة سلبية!) نتيجة للتحليل ، فقد أهدر التحليل.
في حالة وجود وثيقة هندسية عالية المستوى ، فإننا نتحدث عن مجموعة من الآليات أو بنية تغلف هذه الآليات ، والتي يمكن أن تتناسب بشكل مناسب مع حالات الاستخدام الخاصة بنا.
سمح تصميم الأقلمة المحدد هذا بمجموعة من مكونات البرامج والواجهات والسلوكيات التي تشكل بنية نظام الأقلمة. يتم عرض رسم تخطيطي بسيط للبنية المقترحة أدناه.
إذا كنت مهتمًا بمزيد من المعلومات حول الهندسة المعمارية أو التصميم ، فإنني أوصي بشدة بقراءتكالنص الكامل للوثيقة .
تحليل الخطأ
نظرًا لأننا نبني مكونات على أنظمة حرجة للأمان ، فإن الفشل شيء يجب أن نحاول تجنبه أو على الأقل تخفيفه. لذلك ، قبل أن نحاول تصميم أو بناء أي شيء ، يجب أن نكون على الأقل على دراية بكيفية كسر الأشياء.
عند تحليل الأعطال ، كما هو الحال في معظم الحالات ، من المفيد النظر إلى مكون من زوايا متعددة. ل تحليل إخفاقات خوارزمية NDT، اعتبرنا ذلك بطريقتين مختلفتين: كما في (النسبية) آلية توطين العامة، وعلى وجه التحديد كما مثيل خوارزمية NDT.
عند النظر إليه من وجهة نظر آلية التوطين ، يتم صياغة وضع الفشل الرئيسي على النحو التالي - "ماذا تفعل إذا كان الإدخال بيانات غير صحيحة؟" في الواقع ، من وجهة نظر المكون الفردي ، لا يمكن عمل الكثير باستثناء إجراء فحص أساسي لمدى كفاية النظام. على مستوى النظام ، لديك خيارات إضافية (على سبيل المثال ، تمكين ميزات الأمان).
بالنظر إلى NDT كخوارزمية في عزلة ، من المفيد التجريد من الخوارزمية من خلال تسليط الضوء على العدد المناسب من الجوانب. سيكون من المفيد الانتباه إلى إصدار الكود الخوارزمي (هذا سيساعدك ، المطور ، على فهم الخوارزمية بشكل أفضل). في هذه الحالة ، قمنا بتحليل الخوارزمية بالتفصيل ودرسنا جميع المواقف التي يمكن أن تنكسر فيها.
خطأ في التنفيذ هو فشل معقول تمامًا ، على الرغم من أنه يمكن إصلاحه من خلال الاختبار المناسب. بدأت بعض الفروق الدقيقة المتعلقة بالخوارزميات العددية في الظهور بشكل أكثر تكرارًا وأكثر خبثًا. على وجه الخصوص ، نحن نتحدث عن إيجاد مصفوفات عكسية أو ، بشكل أعم ، حل أنظمة المعادلات الخطية ، والتي يمكن أن تؤدي إلى أخطاء عددية. هذا سيناريو فشل حساس للغاية ويجب معالجته.
هناك إخفاقان مهمان آخران حددناهما أيضًا وهما التحقق من أن بعض التعبيرات غير محدودة الحجم (التحكم الدقيق في النقطة العائمة) ، والتحقق من مراقبة حجم أو حجم المدخلات باستمرار.
في المجموع ، قمنا بوضع 15 توصية... أوصي بأن تتعرف عليهم.
سأضيف أيضًا أنه على الرغم من أننا لم نستخدم هذه الطريقة ، فإن تحليل شجرة الأخطاء هو أداة ممتازة لهيكلة وتحديد مشكلة تحليل الفشل.
تعريف المقاييس
"ما يتم قياسه يمكن التحكم فيه"لسوء الحظ ، في التطوير المهني ، لا يكفي تجاهل كتفيك وقول "تم" عندما تتعب من العمل على شيء ما. بشكل أساسي ، تتطلب أي حزمة عمل (والتي هي مرة أخرى تطوير NDT) معايير القبول ، والتي يجب أن يتم الاتفاق عليها من قبل كل من العميل والمورد (إذا كنت كلا من العميل والبائع ، تخطي هذه الخطوة) كل الفقه القانوني موجود لدعم هذه الجوانب ، ولكن كمهندسين يمكننا ببساطة قطع الوسطاء عن طريق إنشاء مقاييس لتحديد مدى توفر مكوناتنا. بعد كل شيء ، فإن الأرقام (في الغالب) لا لبس فيها ولا يمكن دحضها.
- العبارة الشائعة للمديرين
حتى إذا كانت معايير القبول غير ضرورية أو غير ذات صلة ، فلا يزال من الجيد أن يكون لديك مجموعة محددة من المقاييس التي تميز وتحسن جودة وأداء المشروع. في النهاية ، ما يتم قياسه يمكن السيطرة عليه.
من أجل تنفيذ NDT ، قمنا بتقسيم المقاييس إلى أربع مجموعات عريضة:
- مقاييس جودة البرامج العامة
- مقاييس جودة البرامج الثابتة الشائعة
- المقاييس العامة للخوارزمية
- المقاييس الخاصة بالتعريب
لن أخوض في التفاصيل لأن هذه المقاييس كلها قياسية نسبيًا. الشيء المهم هو أنه تم تحديد المقاييس وتحديدها لمشكلتنا المحددة ، وهو ما يمكننا تحقيقه تقريبًا كمطورين لمشروع مفتوح المصدر. في نهاية المطاف ، يجب تحديد شريط القبول بناءً على تفاصيل المشروع من قبل أولئك الذين ينشرون النظام.
آخر شيء سأكرره هنا هو أنه على الرغم من أن المقاييس رائعة للاختبار ، إلا أنها ليست بديلاً للتحقق من فهم التنفيذ ومتطلبات الاستخدام.
العمارة و API
بعد تحديد المشكلة بدقة نحاول حلها وبناء فهم لمساحة الحل ، يمكننا أخيرًا الغوص في المنطقة التي تحد من التنفيذ.
لقد كنت من محبي التنمية المدفوعة باختبار في الآونة الأخيرة . مثل معظم المهندسين ، أحب عملية التطوير ، وبدا أن فكرة كتابة الاختبارات مرهقة بالنسبة لي في المقام الأول. عندما بدأت البرمجة بشكل احترافي ، تقدمت مباشرة واختبرت بعد التطوير (على الرغم من أن أساتذتي الجامعيين طلبوا مني القيام بالعكس). ابحاثتبين أن كتابة الاختبارات قبل التنفيذ تميل إلى أن تؤدي إلى أخطاء أقل ، وتغطية اختبار أعلى ، وكود أفضل بشكل عام. ربما الأهم من ذلك ، أعتقد أن التطوير القائم على الاختبار يساعد على معالجة المشكلة الكبيرة المتمثلة في تنفيذ الخوارزمية.
كيف تبدو؟
بدلاً من تقديم تذكرة متجانسة تسمى "تنفيذ NDT" (بما في ذلك الاختبارات) ، والتي ستؤدي إلى عدة آلاف من الأسطر من التعليمات البرمجية (التي لا يمكن عرضها ودراستها بشكل فعال) ، يمكنك تقسيم المشكلة إلى أجزاء أكثر معنى:
- كتابة فصول وأساليب عامة لخوارزمية (إنشاء بنية)
- اكتب اختبارات الخوارزمية باستخدام واجهة برمجة التطبيقات العامة (يجب أن تفشل!).
- تطبيق منطق الخوارزمية
لذا فإن الخطوة الأولى هي كتابة البنية وواجهة برمجة التطبيقات للخوارزمية. سأغطي الخطوات الأخرى في منشور آخر.
في حين أن هناك العديد من الأعمال التي تتحدث عن كيفية "إنشاء الهندسة المعمارية" ، يبدو لي أن تصميم هندسة البرمجيات له علاقة بالسحر الأسود. أنا شخصياً أحب أن أفكر في التفكير في هندسة البرمجيات على أنها رسم الحدود بين المفاهيم ومحاولة وصف درجات الحرية في طرح مشكلة وكيفية حلها من حيث المفاهيم.
إذن ، ما هي درجات الحرية في NDT؟
تخبرنا مراجعة الأدبيات أن هناك طرقًا مختلفة لتقديم عمليات المسح والملاحظات (مثل P2D-NDT و D2D-NDT). وبالمثل ، تقول ورقتنا الهندسية عالية المستوى أن لدينا عدة طرق لتمثيل الخريطة (ثابتة وديناميكية) ، لذا فهذه أيضًا درجة من الحرية. تشير الأدبيات الحديثة أيضًا إلى إمكانية إعادة النظر في مشكلة التحسين. ومع ذلك ، بمقارنة التنفيذ العملي والأدبيات ، نرى أنه حتى تفاصيل حل التحسين قد تختلف.
والقائمة تطول وتطول.
بناءً على نتائج التصميم الأولي ، توصلنا إلى المفاهيم التالية:
- مشاكل التحسين
- حلول التحسين
- عرض المسح
- عرض الخريطة
- أنظمة توليد الفرضيات الأولية
- واجهات الخوارزمية والعقدة
مع بعض التقسيمات داخل هذه العناصر.
التوقع النهائي للهندسة المعمارية هو أنه يجب أن تكون قابلة للتوسيع وقابلة للصيانة. ما إذا كان بنيتنا المقترحة ترقى إلى مستوى هذا الأمل ، فإن الوقت فقط هو الذي سيخبرنا.
بالإضافة إلى ذلك
بعد التصميم ، بالطبع ، حان الوقت للتنفيذ. العمل الرسمي على تنفيذ NDT في Autoware. تم تنفيذ Auto في أوتواري hackathon التي نظمتها Parkopedia .
وتجدر الإشارة إلى أن ما تم تقديمه في هذا النص هو مجرد التمرير الأول خلال مرحلة التصميم. معروفأنه لا توجد خطة معركة تصمد أمام العدو ، ويمكن قول الشيء نفسه لتصميم البرمجيات. تم تنفيذ الفشل النهائي لنموذج الشلال على افتراض أن المواصفات والتصميم كانا مثاليين. وغني عن القول ، لا المواصفات ولا التصميم مثالي ، ومع تقدم التنفيذ والاختبار ، سيتم اكتشاف العيوب ويجب إجراء تغييرات على التصاميم والوثائق الموضحة هنا.
ولا بأس بذلك. نحن كمهندسين ليسوا عملنا أو نتطابق معه ، وكل ما يمكننا القيام به هو التكرار والسعي من أجل أنظمة مثالية. بعد كل ما قيل عن تطوير NDT ، أعتقد أننا اتخذنا خطوة أولى جيدة.
اشترك في القنوات:
TeslaHackers — Tesla-, Tesla
@AutomotiveRu — ,
: