دليل تطوير منتج IoT من البداية إلى النهاية – مقدمة

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

لماذا تتبع قواعد اللعبة؟ حسنًا، تتضمن مشاريع IoT العديد من الأجزاء المتحركة: الأجهزة وfirmware والخدمات السحابية والتطبيقات، سمها ما شئت. إنه مثل اللعب بكرات متعددة (أو مناشير!) - بدون خطة، قد تسقط واحدة. يجمع دليل التشغيل هذا بين أفضل ما في هندسة الأنظمة الكلاسيكية (للتأكد من أننا لا نفوت أي شيء بالغ الأهمية) مع إيقاع سريع ومتكرر (حتى تتمكن فرق firmware والبرامج السحابية لدينا من التحرك بسرعة والتكيف). باختصار: سنكون منظمين ولكننا لسنا جامدين. الآن، دعونا نقسم الرحلة إلى مراحل واضحة، بدءًا من المرحلة 0 (نعم، نبدأ العد من الصفر، لأن المهندسين 😉) وحتى المرحلة الثامنة وما بعدها. استعدوا ودعنا نبدأ في تحويل فكرة IoT إلى حقيقة!

المرحلة 0: المفهوم والجدوى (“لماذا نفعل هذا؟”)

كل مشروع عظيم يبدأ بـ لماذا. تدور المرحلة 0 حول توضيح الغرض من فكرتك. في مرحلة المفهوم والجدوى هذه، نكتشف سبب وجود هذا المنتج وما إذا كان من المنطقي متابعته. فكر في الأمر على أنه فحص واقعي لفكرتك قبل البدء في استثمار الوقت والمال بشكل جدي.

• الهدف: تحديد الاحتياجات التجارية أو البحثية لمنتجك. ما هي المشكلة التي يحلها؟ من سيهتم؟ إذا لم تتمكن من الإجابة على هذه الأسئلة بوضوح، فهذا هو الوقت المناسب لمعرفة ذلك.
• المخرجات النموذجية: في هذه المرحلة، من المحتمل أن تقوم بصياغة بيان رؤية قصير (جملة أو جملتين واضحتين وملهمتين حول ما تقوم ببنائه ولماذا). يمكنك رسم بعض رحلات المستخدم عالية المستوى - في الأساس، قصص بسيطة عن كيفية تفاعل المستخدم مع جهازك (“تقوم أليس بتثبيت المستشعر في الدفيئة الخاصة بها، وينبه هاتفها الذكي إذا خرجت درجة الحرارة عن النطاق”). ستحتاج أيضًا إلى إجراء تحليل تقريبي للسوق أو تقدير عائد الاستثمار. هل هناك سوق لهذه الأداة؟ هل سيوفر المال أو يحسن الحياة بما يكفي ليريده الناس؟ لا يلزم أن تكون هذه أطروحة مكونة من 50 صفحة - فقط ما يكفي من البحث لمنح الثقة (أو الكشف عن العلامات الحمراء).
• نصيحة: قم بذلك بسرعة – خلال أيام، وليس أسابيع. الفكرة هي التحقق من صحة الفكرة أو إيقافها مبكرًا. إذا كان مفهومك به عيب قاتل (عدم وجود طلب في السوق، أو تكلفة عالية إلى حد جنوني، وما إلى ذلك)، فمن الأفضل بكثير أن تكتشف أنك قبل أن تقضي أشهرًا في تصميم نموذج أولي. فكر في المرحلة 0 كمرشح: فهي تلتقط الأفكار السيئة حتى لا تهدر الموارد، وتسمح للأفكار الواعدة بالمرور. كن صادقًا مع نفسك هنا؛إنه مثل الاختبار الأولي قبل العرض الكبير. إذا كان هناك شيء لا يبدو قابلاً للتطبيق، فلا بأس في تركه جانبًا والانتقال إلى الفكرة التالية.

بحلول نهاية المرحلة 0، يجب أن يكون لديك إجابة واضحة لسؤال “لماذا نفعل هذا؟“والثقة بأن الفكرة تستحق المتابعة. إذا قمت بذلك، تهانينا – لقد حصلت على الضوء الأخضر للمضي قدمًا!🎉 وإذا لم يكن الأمر كذلك، فلا تثبط عزيمتك؛من الأفضل أن نفشل سريعًا في مرحلة الفكرة بدلاً من أن نفشل لاحقًا عندما تكون المخاطر (والتكاليف) أعلى.

المرحلة 1: متطلبات أصحاب المصلحة والنظام (الأشياء الأولى أولاً!)

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

ما هي “المتطلبات”؟ في الأساس، هي قائمة تفصيلية بـ ما يجب أن يفعله المنتج وتحت أي ظروف. يتضمن ذلك فئات مختلفة من المتطلبات:

• المتطلبات الوظيفية: تصف هذه المتطلبات ما يفعله المنتج. بالنسبة لمستشعر IoT، قد تغطي المتطلبات الوظيفية البيانات التي يتم استشعارها (مثل درجة الحرارة والرطوبة)، وبأي دقة، وعدد مرات أخذ القراءات (معدل التحديث)، ومدى السرعة التي يجب أن يتم بها تسليم البيانات (زمن الوصول). فهو يجيب على أسئلة مثل: ما هي الميزات التي سيتمتع بها المنتج؟ ما هي المهام التي يجب أن يؤديها؟ على سبيل المثال، “يجب على الجهاز قياس درجة الحرارة من 0 درجة مئوية إلى 50 درجة مئوية بدقة ±0. 5 درجة مئوية وإرسال القراءات إلى السحابة كل 10 دقائق”.
• المتطلبات غير الوظيفية: تغطي هذه المتطلبات قيود المنتج وصفاته - أشياء مثل استهلاك الطاقة (على سبيل المثال، يجب تشغيله على البطارية لمدة عام واحد على الأقل)، والموثوقية وطول العمر (متوسط الوقت بين حالات الفشل، المعروف أيضًا باسم MTBF، ربما يحتاج إلى التشغيل لمدة 5 سنوات دون أن يتعطل)، واعتبارات الأمان/الخصوصية (يجب تشفير البيانات، ويجب حماية بيانات المستخدم)، وحدود التكلفة (يجب ألا تتجاوز تكلفة الوحدة 50 دولارًا أمريكيًا)،وأي معايير تنظيمية يجب أن تستوفيها (على سبيل المثال، الامتثال لقواعد CE أو FCC للإلكترونيات، أو معيار السلامة مثل ISO 13849 إذا تم استخدامه في الآلات). المتطلبات غير الوظيفية لا تقل أهمية عن الميزات البراقة؛فهم يضمنون أن المنتج آمن، وقوي، وقابل للتطبيق في العالم الحقيقي.
• متطلبات الواجهة: تحدد كيفية تفاعل منتجك مع العالم الخارجي. يتضمن ذلك الواجهات الكهربائية (على سبيل المثال، هل يخرج إشارة 0-5 فولت إلى جهاز آخر؟ هل يستخدم USB-C للطاقة؟)، الواجهات الميكانيكية (الأبعاد المادية ونقاط التثبيت والموصلات - هل ستتناسب مع حاوية أو فتحة معينة؟ هل يجب أن تكون مقاومة للماء؟)، وواجهات الاتصال مثل واجهات برمجة التطبيقات السحابية أو تطبيقات الهاتف المحمول (على سبيل المثال، “يجب أن يوفر الجهاز نقطة نهاية REST API لاسترداد بيانات المستشعر” أو “يجب الاتصال عبرBLE إلى تطبيق الهاتف الذكي”). في الأساس، كيف سيتم توصيل جميع الأجزاء (الجهاز، السحابة، التطبيق، والأنظمة الأخرى) معًا والتحدث مع بعضها البعض؟

كيف يمكننا الحصول على هذه المتطلبات؟ عمليًا، يمكنك كتابة وثيقة متطلبات رسمية أو الاحتفاظ بقائمة منظمة في أداة إدارة المشروع. تستخدم بعض الفرق قالبًا يستند إلى IEEE 29148\ لمتطلبات النظام (وهو تنسيق موحد رائع لمتطلبات الكتابة - رائع للدقة). يستخدم البعض الآخر نهجًا أكثر مرونة، مثل قائمة الملاحم وقصص المستخدمين في Jira أو wiki. أيًا كان التنسيق الذي تختاره، تأكد من أن كل متطلبات واضحة وقابلة للاختبار. من العادات الجيدة وضع علامة على كل متطلب مع كيفية التحقق منه لاحقًا - هل سيتم التحقق منه عن طريق الاختبار، أو الفحص، أو التحليل، أو بعض الشهادات؟ على سبيل المثال، إذا كان لديك مطلب “يجب أن يتمتع الجهاز بتصنيف IP67 لمقاومة الماء”، ستعرف لاحقًا أنك ستحتاج إلى إجراء اختبار دخول الماء للتحقق من ذلك.

الآن، لماذا الإصرار على القيام بذلك ** أولا **؟ لأن كل تصميم واختبار وفحص امتثال لاحق سيرجع إلى هذه المتطلبات. فهي بمثابة نجم الشمال لمشروعك. إذا تقدمت في التصميم دون متطلبات قوية، فقد تقوم ببناء شيء خاطئ، أو تفوت شيئًا بالغ الأهمية (تخيل تصميم جهاز جميل ثم يقول شخص ما، “في الواقع، كان هناك حاجة أيضًا لقياس الرطوبة”، ولم يتبق لديك مساحة على لوحة الدوائر المطبوعة الخاصة بك لهذا المستشعر - عفوًا!). إن تغيير المتطلبات أو توضيحها الآن أرخص بكثير وأسهل من إعادة كتابة firmware أو إعادة توجيه PCB لاحقًا. القليل من الفكاهة لتذكر هذه المرحلة: تغيير رأيك بشأن أحد المتطلبات لاحقًا يشبه اتخاذ قرار بإضافة غرفة نوم إضافية بعد بناء منزلك - إنه أمر ممكن، لكنه مؤلم ومكلف. لذا، احصل على هذه المتطلبات بشكل صحيح في وقت مبكر. قم بإشراك جميع أصحاب المصلحة (التسويق، والهندسة، والعملاء، وما إلى ذلك) للتأكد من عدم تفويت أي شيء مهم. ونتيجة لذلك، سيكون لديك مخطط واضح لما يجب أن يحققه المنتج، والذي يرشد الجميع (مهندسي الأجهزة، ومطوري البرامج، والمختبرين، وما إلى ذلك) في المراحل التالية.

المرحلة 2: هندسة النظام (التخطيط على الورق قبل البناء)

مع وجود متطلبات قوية في متناول اليد، حان الوقت لـ بنية النظام - وهي في الأساس خطة اللعبة عالية المستوى لكيفية تلبية هذه المتطلبات. فكر في الهندسة المعمارية كتصميم للمدينة قبل البدء في تشييد المباني. أنت من يقرر أين تذهب الطرق والجسور قبل صب الخرسانة. في مشروعنا لIoT، يعني ذلك رسم النظام العام على الورق أو السبورة البيضاء (يُعد استخدام “الورقة” الرقمية أمرًا جيدًا أيضًا) قبل حدوث أي لحام أو تشفير. تدور هذه المرحلة حول التفكير بالصورة الكبيرة واتخاذ القرارات الأساسية التي ستشكل تصميم منتجك.

إليك ما يحدث في بنية النظام:

• مخطط كتلة النظام بأكمله: يمكنك رسم جميع المكونات الرئيسية وكيفية اتصالها. على سبيل المثال، قد يكون المخطط التفصيلي البسيط كما يلي: المستشعر ← MCU (MCU/SoC) ← الراديو اللاسلكي ← خادم السحابة ← عميل الويب/الهاتف المحمول. يوضح هذا المسار الشامل: يقوم المستشعر بتغذية البيانات إلى وحدة MCU، والتي قد تقوم ببعض المعالجة ثم تستخدم الراديو (مثل Wi-Fi أو Bluetooth أو LoRa وما إلى ذلك) لإرسال البيانات إلى خادم في السحابة، مما يجعلها متاحة بعد ذلك لواجهة المستخدم (لوحة تحكم الويب أو تطبيق الهاتف المحمول). من خلال وجود هذا المخطط، يمكن للجميع رؤية جميع القطع المعنية في لمحة واحدة.
• قرارات التقسيم: الآن بعد أن رأيت الأجزاء، قرر ما هي المسؤوليات التي تقع فيها. يتعلق الأمر بتقسيم المهام بين الأجهزة وfirmware والسحابة. على سبيل المثال، هل ستتعامل مع تشفير البيانات على الجهاز (بحيث تكون البيانات آمنة حتى قبل أن تغادر صندوق المستشعر)، أم ستفعل ذلك في السحابة؟ هل يجب معالجة بيانات المستشعر مسبقًا على الجهاز (على سبيل المثال، التصفية أو المتوسط) أم إرسالها فقط إلى السحابة حيث يمكن أن تحدث عمليات حوسبة ثقيلة؟ تؤثر هذه القرارات على متطلبات الأجهزة (هل تحتاج إلى وحدة MCU أكثر قوة للمعالجة على الجهاز؟) وتعقيد البرامج (قد تكون السحابة أبسط إذا كان الجهاز يقوم بالمزيد، أو العكس). إنه نوع من التوازن - فأنت تريد أن يتعامل كل جزء من النظام مع ما هو الأفضل فيه. غالبًا ما تكرر هذه الاختيارات: ربما تخطط في البداية للقيام بكل شيء على وحدة MCU صغيرة، ولكن بعد ذلك تدرك أن الذاكرة محدودة للغاية، لذا تقوم بنقل بعض الوظائف إلى السحابة، وما إلى ذلك. هذا هو بالضبط نوع الرؤية التي تريد الحصول عليها الآن، في مرحلة الهندسة المعمارية، وليس لاحقًا عندما تكون قد كتبت بالفعل تعليمات برمجية أو صنعت PCB لا يمكنه التعامل معها.- اختيار التكنولوجيا: بناءً على المتطلبات والمخطط التخطيطي، ابدأ في اختيار التقنيات المرشحة لكل جزء. هذا هو المكان الذي تختار فيه، على سبيل المثال، أي مستشعر (أجهزة) تستخدم (هل تحتاج إلى مستشعر رقمي عالي الدقة أو شيء تناظري مع ADC؟)، ما هي عائلة MCU أو SoC التي قد تناسبك (هل تحتاج إلى طاقة منخفضة للغاية؟ سرعة عالية؟ الكثير من ذاكرة الوصول العشوائي؟ أي منصة بيع محددة تفضلها؟)، وما هي طريقة الاتصال التي تناسب حالة الاستخدام الخاصة بك (Bluetooth Low Energy للاتصال قصير المدى والهاتف، Wi-Fi إذا كان هناك إنترنت محلي، LTE-M/NB-IoT إذا كان ذلكيحتاج إلى شبكة خلوية، وLoRa إذا كان النطاق الترددي المنخفض طويل المدى هو المفتاح، وما إلى ذلك). لا تقم بالضرورة بوضع اللمسات النهائية على أرقام الأجزاء الدقيقة بعد، ولكنك تقوم بتضييق نطاقها (على سبيل المثال، “من المحتمل أن نستخدم ARM Cortex-M4 MCU، مع راديو Semtech LoRa”). فكر أيضًا في أشياء مثل الطاقة: هل سيتم تشغيلها بالبطارية، وإذا كان الأمر كذلك فما هو نوعها (الخلايا المعدنية مقابل Li-ion)؟ إذا كان يعمل بالبطارية، فهذا يستبعد على الفور بعض التقنيات عالية الطاقة. بشكل أساسي، أنت تقوم بتشكيل المكدس التقني للمشروع هنا.
• تحليل المخاطر والتكلفة: حتى في هذه المرحلة المبكرة، حدد المخاطر المحتملة أو عوامل التكلفة. هل يعتمد تصميمك على مكون واحد باهظ الثمن أو يستغرق مهلة 30 أسبوعًا؟ (في مجال الأجهزة، يعد هذا مصدر قلق حقيقي - في بعض الأحيان تكون الشريحة مثالية ولكنها دائمًا غير متوفرة في المخزون 😫.) هل هناك أي “نقاط فشل فردية” في نظامك؟ (على سبيل المثال، إذا فقد الجهاز الاتصال بالسحابة، فهل يصبح المنتج بأكمله عديم الفائدة؟ ربما تحتاج إلى بعض وحدات التخزين المحلية كنسخة احتياطية.) ضع في اعتبارك أيضًا تحديات الاعتماد أو الامتثال: على سبيل المثال. قد يتطلب استخدام تردد لاسلكي معين الحصول على شهادة معقدة. من خلال وضع علامة على هذه الأمور الآن، يمكنك التخطيط للتخفيف من المخاطر - ربما يكون لديك مكون احتياطي في الاعتبار، أو التخطيط لوقت إضافي لاختبار الشهادات، وما إلى ذلك. ومن الأفضل كثيرًا أن تدخل وأعين مفتوحة على المخاطر الكبيرة بدلاً من أن تتفاجأ لاحقًا.
• التوثيق والتدوين: ستحتاج إلى تصوير التصميم بطريقة مفهومة وقابلة للمشاركة. تستخدم العديد من الفرق لغات النمذجة المرئية: SysML أو نموذج C4 البسيط لمخططات سياق النظام يمكن أن يُظهر عرضًا متعدد التخصصات (الأجهزة والبرامج والمستخدمين وكلهم يتفاعلون). بالنسبة لعناصر البرنامج (firmware والسحابة)، يمكن أن يوضح مخطط مكونات UML كيفية تقسيم أجزاء البرنامج (على سبيل المثال، الأجزاء التي تعمل على الجهاز مقابل الأجزاء التي تعمل على الخادم). ولكن لا تقلق إذا كانت هذه الاختصارات تبدو مخيفة - فحتى المربعات والأسهم المرسومة يدويًا أو شريحة PowerPoint يمكن أن تؤدي المهمة، طالما أنها واضحة. يبدأ بعض الأشخاص أيضًا قائمة المواد (BOM) ​​الأساسية في جدول بيانات في هذه المرحلة، مع إدراج المكونات الرئيسية (المستشعر، MCU، وحدة الراديو، وما إلى ذلك) مع التكاليف التقريبية وأي ملاحظات (مثل المهل الزمنية أو البائع). يساعد هذا على ضمان قدرة المنتج على تحقيق أهداف التكلفة الخاصة به وأنك على دراية بأي تحديات تتعلق بالمصادر في وقت مبكر.

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

أخيرًا، بحلول نهاية المرحلة الثانية، يجب أن يكون لديك مخطط واضح: تصميم عالي المستوى يوضح كيف تنوي تلبية المتطلبات. إنه مثل الرسم المعماري للمبنى - أنت لم تحدد لون الطلاء بعد، لكنك تعرف عدد الطوابق التي سيتكون منها وأين ستكون الأبواب والنوافذ. بعد أن أصبح هذا المخطط جاهزًا، أصبحت مستعدًا للتعمق في التصميم التفصيلي بثقة.## المرحلة 3: الإلكترونيات والتصميم الميكانيكي (“الجانب الأيسر” من حرف V)

نصل الآن إلى المتعة العملية: تصميم الأجهزة الفعلية! تغطي المرحلة 3 التصميم الإلكتروني والميكانيكي، اللذين غالبًا ما يسيران جنبًا إلى جنب. إذا كنت قد سمعت عن نموذج V في الهندسة (نموذج عملية تطوير كلاسيكي)، فإن “الجانب الأيسر” من V يدور حول التصميم والتنفيذ. هذا هو ما نحن فيه الآن - تصميم الأجهزة التي سيتم التحقق منها لاحقًا والتحقق من صحتها على الجانب الأيمن من V. ولكن لا تقلق إذا لم تكن على دراية بهذا المصطلح؛الفكرة الأساسية هي أن تصميم الأجهزة أكثر تسلسلاً ويجب إجراؤه بعناية، لأنه بمجرد طباعة لوحة دوائر أو تشكيل علبة بلاستيكية، تكون التغييرات صعبة بعض الشيء (اقرأ: باهظة الثمن 😬).

يمكن تقسيم المرحلة 3 إلى بضع خطوات فرعية، والأهم من ذلك، أن هذا هو المكان الذي يبدأ فيه تطوير الأجهزة والبرامج العمل بالتوازي (المزيد عن البرنامج في المرحلة التالية). إليك كيفية ظهور جانب الأجهزة عادةً:

• التقاط تخطيطي: هذا هو المكان الذي يتم فيه رسم تصميم الدائرة بالتفصيل. باستخدام أدوات التصميم بمساعدة الكمبيوتر (مثل Altium، وEagle، وKiCad، وما إلى ذلك)، يقوم مهندس الإلكترونيات بإنشاء مخطط تخطيطي: رسم تخطيطي إلكتروني يوضح جميع المكونات (MCU، وأجهزة الاستشعار، والمكثفات، والموصلات، وما إلى ذلك) وكيفية اتصالها بالشبكات (الأسلاك). بمجرد أن يصبح المخطط جاهزًا، من المهم إجراء مراجعة - غالبًا ما يتم توزيع ملف PDF للمخطط التخطيطي للأقران لاكتشاف الأخطاء (مثل “عفوًا، دبوس طاقة المستشعر غير متصل!” أو “يبدو أن قيمة المقاوم هذه معطلة”). في هذه المرحلة، تقوم بعض الفرق أيضًا بإجراء FMEA (تحليل أوضاع الفشل وتأثيراته) خاصة للدوائر المهمة مثل مصدر الطاقة أو أي أجزاء متعلقة بالسلامة. FMEA هي طريقة رائعة للقول “فكر في كل الطرق التي يمكن أن يفشل بها هذا الأمر وتأكد من أن لدينا إجراءات تخفيف أو أن المخاطر مقبولة”. على سبيل المثال، _ماذا لو تعطلت دائرة قصر مستشعر درجة الحرارة؟ هل سيؤدي ذلك إلى إتلاف اللوحة أم مجرد إرجاع الحد الأقصى للقراءة؟ _ معالجة مثل هذه الأسئلة مبكرًا تعمل على تحسين الموثوقية. وفي الوقت نفسه - وهذا هو المفتاح - ** بالتوازي ** يمكن أن يبدأ القليل من العمل البرمجي. يمكن لفريق firmware البدء في إنشاء هيكل HAL (طبقة تجريد الأجهزة) استنادًا إلى المخطط. بشكل أساسي، يقومون بإعداد واجهات برمجية للأجهزة الطرفية لMCU (مثل برامج تشغيل I2C أو SPI إذا كانت تلك المستشعرات تستخدم تلك الناقلات) ويمكنهم أيضًا كتابة اختبارات الوحدة لهذه الأجهزة على جهاز كمبيوتر (بدون أجهزة). ويعني هذا الجهد الموازي أن العاملين في مجال البرمجيات لا يعبثون بإبهامهم في انتظار اللوحات؛إنهم يضعون الأساس الذي سيجعل عملية طرح الأجهزة أسهل لاحقًا.- تخطيط PCB: بمجرد الانتهاء من التخطيط، يحين وقت PCB (لوحة الدوائر المطبوعة). تخطيط PCB هو المكان الذي تضع فيه كل هذه المكونات على شكل لوحة وتوجيه آثار النحاس لتوصيل كل شيء، مرة أخرى باستخدام برنامج CAD. تنتج هذه المرحلة مخرجات مثل ملفات Gerber (الملفات التي يحتاجها المصنعون لتصنيع اللوحة فعليًا) وغالبًا نموذج ثلاثي الأبعاد (ملف STEP) للوحة، وهو أمر مفيد للغاية للتكامل الميكانيكي (التحقق من ملاءمة اللوحة في العلبة، وما إلى ذلك). أثناء تخطيط PCB، عليك أيضًا أن تضع في اعتبارك إرشادات التصميم للتصنيع (DFM) والتصميم للاختبار (DFT) - مما يضمن بشكل أساسي إمكانية تصنيع اللوحة الخاصة بك بشكل موثوق وأنه يمكنك اختبارها بسهولة لاحقًا. على سبيل المثال، قد ترغب في إضافة منصات اختبار أو موصلات لبرمجة firmware واختبار الإشارات على اللوحة. غالبًا ما يتم استخدام قائمة المراجعة حتى لا ننسى أشياء مثل المستندات الائتمانية (لآلات الانتقاء والمكان)، والتصاريح، ووضع العلامات، وما إلى ذلك. أثناء وضع اللوحة، يمكن لفريق البرمجيات التقدم بالتوازي: يمكنهم محاكاة أو إيقاف برامج تشغيل أجهزة الاستشعار (إذا كانوا يعرفون نموذج المستشعر من المخطط، فقد يكتبون تعليمات برمجية مقابل ورقة بيانات أو يستخدمون محاكي أجهزة الاستشعار). قد يقوم فريق السحابة بإعداد هيكل عظمي للواجهة الخلفية (ربما تصميم مخطط قاعدة البيانات لبيانات المستشعر، أو إعداد خادم أساسي يمكنه قبول نقطة بيانات). تضمن هذه المهام المتوازية أنه بحلول وقت وصول الأجهزة، لن تبدأ firmware والسحابة من الصفر - بل إنهما جاهزان للتكامل.
• بناء النموذج الأولي: بعد الانتهاء من تخطيط PCB، يمكنك إرسال هذه الـ Gerbers إلى القوات المسلحة البوروندية (يستخدم العديد منها الشركات المصنعة لPCB سريع الدوران) وطلب الأجزاء (إذا لم تكن قد قمت بذلك بالفعل).نصيحة احترافية: اطلب الأجزاء المهمة بمجرد التأكد من المخطط/البصمة الخاصة بك! يمكن أن تستغرق بعض الأجزاء فترات زمنية طويلة (درس تعلمه الكثيرون بالطريقة الصعبة أثناء نقص الرقائق). اطلب مبكرًا، وبحلول الوقت الذي تصل فيه اللوحات، يكون لديك بالفعل الرقائق التي يمكنك وضعها عليها. بمجرد إدخال الألواح والأجزاء، يمكنك تجميع عدد قليل من وحدات النماذج الأولية - ويمكن أن يتم ذلك داخل الشركة إذا كان لديك مختبر وأيدي لحام ثابتة، أو عبر خدمة التجميع. الآن اللحظة المثيرة: تنشئة اللوحة الأولى. يتضمن ذلك تشغيله (غالبًا بأصابع متقاطعة ومصدر طاقة محدود حاليًا … فقط في حالة) والتحقق من عمل الأساسيات. هل تقوم وحدة MCU بتشغيل وتشغيل التعليمات البرمجية؟ هل قضبان الطاقة في الفولتية الصحيحة؟ هل يمكنك التواصل مع المستشعر عبر I2C/SPI، وما إلى ذلك؟ غالبًا ما تقوم بتوصيل مصحح أخطاء أو وحدة تحكم تسلسلية لمعرفة ما إذا كان البرنامج الثابت نشطًا (حتى وميض مؤشر LED أو طباعة “Hello” يعد فوزًا كبيرًا في هذه المرحلة!). يمكنك أيضًا التحقق من وجود أي مشاكل في الطاقة أو الحرارة - على سبيل المثال. لا يوجد شيء محموم أو يستهلك طاقة أكثر من المتوقع. إذا كنت تخطط للامتثال التنظيمي (على سبيل المثال، اختبارات الانبعاثات الصادرة عن لجنة الاتصالات الفيدرالية)، فيمكنك إجراء مسح مسبق في المختبر فقط لمعرفة ما إذا كنت في الملعب أو ما إذا كان هناك شيء ما يصرخ بتردد غير متوقع. أثناء عرض النموذج الأولي، يقوم فريق firmware الآن باختبار التعليمات البرمجية الخاصة به على أجهزة حقيقية - كتابة برامج تشغيل المستشعرات هذه بشكل حقيقي، وضبط مهام RTOS (في حالة استخدام RTOS)، وما إلى ذلك. قد يبدأ فريق السحابة في رؤية البيانات الحقيقية تأتي والتحقق من التدفق الشامل على نطاق صغير.

غالبًا ما تتضمن المرحلة 3 بعض التكرارات: قد تجد خطأً على اللوحة وتضطر إلى إصلاحه أو تدوير المراجعة. هذا طبيعي! ولهذا السبب نقوم ببناء نماذج أولية – للتعلم والتحسين. يعد التعاون الوثيق بين الأجهزة والبرامج أمرًا حيويًا هنا؛ومع ظهور المشكلات، تعمل الفرق معًا لاستكشاف الأخطاء وإصلاحها. على سبيل المثال، إذا كان المستشعر لا يقرأ، فهل هذا خطأ في البرنامج الثابت أم مشكلة في الأسلاك؟ يقوم كلا الجانبين بالتحقيق.

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

ملاحظة جانبية فكاهية: في المرة الأولى التي ينبض فيها النموذج الأولي بالحياة ويرسل البيانات إلى الشاشة، لا بأس أن تشعر قليلاً وكأن الدكتور فرانكنشتاين يصرخ “إنه حي!”- نحن جميعًا نقوم برقصة سعيدة صغيرة عند نجاحنا في التنشئة. ربما لا تصرخ بها حرفيًا في المختبر؛إنه يخيف المتدربين.

المرحلة 4: تطوير firmware والبرمجيات السحابية (التكرار “Right-Hand V”)

بينما كان تصميم الأجهزة هو الجانب الأيسر من V، المرحلة 4 هي الجانب الأيمن - تطوير firmware (البرنامج الذي يعمل على الجهاز) والبرمجيات السحابية (الخوادم وقواعد البيانات وواجهات برمجة التطبيقات وواجهات المستخدم). عادةً ما تكون هذه المرحلة أكثر تكرارًا وتعمل بالتوازي مع تطوير الأجهزة. في الواقع، من المحتمل أنك بدأت بالفعل بعض أعمال firmware في المرحلة 3 (أثناء التخطيط/التخطيط). الآن يتصاعد بشكل كامل. يتمثل النهج الرئيسي هنا في استخدام ممارسات تطوير البرامج الحديثة حتى تتمكن من الإنشاء والاختبار والتحسين بسرعة - على عكس الأجهزة، من السهل تغيير البرامج بسرعة، لذلك نستفيد من هذه السرعة.

يمكن تقسيم المرحلة الرابعة إلى جزأين: الهندسة/التصميم للبرامج، ودورة التطوير المستمرة.

4. 1 هندسة البرمجيات وتصميمها

قبل أن يقفز الجميع إلى عالم البرمجة بجنون، من الحكمة رسم بنية البرنامج لكل من firmware ومكونات السحابة. وهذا مشابه لبنية النظام التي قمنا بها في المرحلة الثانية، ولكن على مستوى الكود. الأشياء الأساسية لتأسيسها:

• بنية firmware: تحديد طبقات ومكونات التعليمات البرمجية المضمنة لديك. النهج الشائع هو البنية الطبقية: على سبيل المثال، في الجزء السفلي لديك حزمة دعم اللوحة (BSP) أو برامج تشغيل منخفضة المستوى (لوحدة MCU، والأجهزة الطرفية، وما إلى ذلك)، وفوق ذلك لديك طبقة تجريد الأجهزة وبرامج تشغيل الأجهزة لأجهزة الاستشعار/المشغلات، وفوق ذلك ربما تكون هناك طبقة خدمات (مثل خدمات الاتصالات، وخوارزميات معالجة البيانات)، وفي الجزء العلوي منطق التطبيق (الكود الذي يربط كل ذلك معًا وفقًا لغرض منتجك). يمكنك رسم رسم تخطيطي بسيط (مخطط حزمة UML أو مجرد مربعات) يوضح هذه الطبقات. ضع في اعتبارك أيضًا استخدام RTOS (RTOS) إذا كان جهازك يتضمن مهام متعددة (مثل قراءة أجهزة الاستشعار، وإرسال البيانات، وتحديث مصابيح LED، وما إلى ذلك بشكل متزامن). في حالة استخدام نظام RTOS، فإن جزءًا من تصميم البنية هو تحديد هيكل المهمة (على سبيل المثال، مهمة واحدة لأخذ عينات من أجهزة الاستشعار، وواحدة للاتصالات، وواحدة للتدبير المنزلي، وما إلى ذلك) وكيفية التواصل (قوائم انتظار الرسائل، والبيانات المشتركة المحمية بواسطة كائنات المزامنة، وما إلى ذلك). سيساعد تصميم هذا بشكل واضح على تجنب وحش “رمز السباغيتي” المخيف ويجعل صيانة firmware أسهل.
• الهندسة السحابية: ينطبق التفكير نفسه على الجانب السحابي. إذا كان لديك خادم ويب أو نظام أساسي لIoT يتلقى البيانات، فحدد مكوناته. على سبيل المثال، قد تكون هناك طبقة API (استقبال بيانات الجهاز والتعامل مع طلبات المستخدم)، وقاعدة بيانات (تخزين قراءات المستشعر، ومعلومات المستخدم، وما إلى ذلك)، وربما بعض خدمات المعالجة أو التحليلات (مثل تشغيل التنبيهات إذا خرجت البيانات عن النطاق، وما إلى ذلك). ضع في اعتبارك أيضًا جانب العميل: ربما تطبيق ويب أو تطبيق جوال يجلب البيانات من السحابة. يمكنك استخدام مخطط نموذج C4 على مستوى الحاوية لإظهار كيفية تفاعل الأجزاء (الجهاز، الخادم، قاعدة البيانات، تطبيق العميل). الهدف هو الحصول على نموذج عقلي واضح (وربما نموذج مرئي) للنظام البيئي للبرنامج.- بروتوكولات الاتصال وتنسيقات البيانات: جزء من التصميم هو الموافقة على كيفية اتصال الجهاز بالسحابة. هل ستستخدم MQTT؟ واجهة برمجة تطبيقات HTTP/REST؟ CoAP؟ حدد البروتوكول وقم بتصميم تنسيق البيانات (على سبيل المثال، حمولات JSON مع حقول معينة، أو تنسيق ثنائي إذا كنت بحاجة إلى الكفاءة). قد يتضمن ذلك مخططات تسلسلية - على سبيل المثال، مخططات التسلسل يمكن أن توضح كيفية أخذ قراءة المستشعر على الجهاز، وتعبئتها، وإرسالها إلى السحابة، والإقرار بها، ثم عرضها للمستخدم. وهذا يضمن أن يكون كل من مهندسي firmware والسحابة حرفيًا “على نفس الصفحة” بشأن تدفق الرسائل.
• معايير وأدوات الترميز: كفريق، اتفقوا على كيفية كتابة التعليمات البرمجية. بالنسبة للغة C المضمنة، تتبنى العديد من الفرق إرشادات MISRA-C (مجموعة من القواعد لتجنب بنيات لغة C المزعجة). بالنسبة إلى لغة C++، ربما تكون إرشادات C++ الأساسية أو مجموعة فرعية من ميزات C++ الحديثة الآمنة للتضمين. بالنسبة إلى Python (في حالة استخدام السحابة أو البرمجة النصية)، دليل نمط PEP 8، وما إلى ذلك. الفكرة هي الحفاظ على اتساق التعليمات البرمجية وتجنب المخاطر الشائعة. اختر أيضًا الأدوات: يجب تحديد التحكم في الإصدار (من المحتمل جدًا Git)، وتتبع المشكلات، وإعداد النظام الأساسي CI (التكامل المستمر). قد يبدو هذا إجراءً إجرائيًا، لكنه مهم – فمن الأسهل بكثير فرض جودة التعليمات البرمجية عندما يتفق الجميع على القواعد من البداية.

باختصار، تدور المرحلة 4. 1 حول تخطيط البرنامج بشكل كافٍ حتى يعرف الجميع الحدود والواجهات. إن الأمر يشبه التخطيط لرحلة على الطريق: تحدد المسار وتتوقف، لكن لا تقوم بالضرورة بكتابة نص كل دقيقة - هناك مجال للتكرار مرة واحدة على الطريق.

4. 2 سباقات التطوير (التكرار والقهر)

الآن تبدأ المتعة بشكل جدي: كتابة التعليمات البرمجية، واختبارها، وإظهار نجاحها - في دورات متكررة. يتم ذلك غالبًا في سباقات السرعة (عادةً ما تستغرق من 2 إلى 4 أسابيع). تتمثل فكرة السباق السريع في أخذ مجموعة من الميزات (قصص المستخدم) من الأعمال المتراكمة (التي تم استرشادها بالمتطلبات الموجودة في المرحلة 1) وتنفيذها، مما يؤدي إلى إنتاج زيادة محتملة قابلة للشحن للمنتج في نهاية السباق. دعونا نحلل كيف يبدو هذا:

• تخطيط السبرنت وقصص المستخدمين: ينظر الفريق إلى الأعمال المتراكمة ذات الأولوية ويسحب بعض قصص المستخدم أو المهام إلى السبرنت. على سبيل المثال، قد تكون القصة “كمستخدم، أريد أن يرسل الجهاز بيانات درجة الحرارة إلى السحابة كل 10 دقائق.”أثناء التخطيط، يوضح المطورون معايير القبول (على سبيل المثال، ما الذي يستلزمه بالضبط “الإرسال إلى السحابة”؟ كيف سنعرف أنه يعمل؟).
• التنفيذ والتكامل المستمر: أثناء السباق، يكتب المطورون تعليمات برمجية للبرامج الثابتة وميزات السحابة. ويكتبون أيضًا الاختبارات الآلية لهذا الرمز. أفضل الممارسات هي استخدام التكامل المستمر (CI) - نظام مثل GitHub Actions وGitLab CI وJenkins وما إلى ذلك، الذي يبني التعليمات البرمجية تلقائيًا ويجري الاختبارات في كل مرة تقوم فيها بإجراء تغييرات. بالنسبة للبرامج الثابتة، قد يتضمن ذلك تشغيل اختبارات الوحدة على جهاز مضيف أو حتى على إعداد الأجهزة داخل الحلقة (حيث يتم استخدام جهاز حقيقي أو جهاز محاكاة في الاختبار). بالنسبة للسحابة، يتضمن هذا بالتأكيد تشغيل جميع اختبارات الخادم/التطبيق. والفكرة هي التقاط الأخطاء بسرعة. غالبًا ما تقوم الفرق أيضًا بدمج أدوات التحليل الثابت (التي تفحص الكود بحثًا عن الأخطاء أو المشكلات الأسلوبية) وتقيس تغطية الكود (للتأكد من أن الاختبارات تصل إلى معظم الكود). على سبيل المثال، قد تفرض، على سبيل المثال، تنفيذ ما لا يقل عن 80% من التعليمات البرمجية الخاصة بك عن طريق الاختبارات، وعدم السماح بأي تحذيرات تحليلية ثابتة حرجة.- الإنشاءات التزايدية: بحلول نهاية كل سباق، تهدف إلى الحصول على الإنشاء التزايدي للنظام بأكمله - إصدار من البرنامج الثابت الذي يمكن تثبيته على جهاز وإصدار من برنامج السحابة (ربما يتم نشره في بيئة اختبار أو كحاويات Docker) يعملان معًا. على سبيل المثال، في نهاية Sprint 1، ربما يكون لديك تدفق أساسي من طرف إلى طرف: يقرأ الجهاز قيمة مستشعر وهمية ويرسلها بنجاح إلى السحابة، ويمكنك رؤيتها في عارض قاعدة بيانات بسيط. بواسطة Sprint 2، ربما تكون القراءة من المستشعر الحقيقي ولديك لوحة تحكم ويب أساسية تعرض نقطة واحدة. بواسطة Sprint N، لديك كافة الميزات التي تم تنفيذها. المفتاح هو التقدم التكراري - تضيف كل دورة المزيد من الوظائف والإصلاحات.
• معايير الاختبار والتنفيذ: تعتبر كل قصة مستخدم أو ميزة “مكتملة” فقط عند استيفاء معايير معينة. قد تتضمن قائمة التحقق الشائعة تعريف تم ما يلي:
• يتم كتابة الكود الخاص بالميزة ويتم إنشاؤه بدون أخطاء.
• اختبارات الوحدة التي تغطي الكود الجديد تم اجتيازها (وربما تتم كتابة اختبارات جديدة إذا لزم الأمر).
• اختبارات التكامل (إذا كانت الميزة تتفاعل مع أجزاء أخرى) ناجحة - على سبيل المثال. إذا قمت بإضافة واجهة برمجة تطبيقات سحابية، فيجب اجتياز الاختبار الذي يستدعي API هذه ويتوقع الاستجابة الصحيحة.
• لا يُظهر التحليل الثابت أي تحذيرات جديدة (ولا يُظهر أي تحذيرات قديمة أيضًا).
• تمت مراجعة الكود ** من قبل النظراء ** (راجعه مطور آخر ووافق عليه).
• يتم تحديث الوثائق إذا لزم الأمر (قد يكون ذلك بسيطًا مثل تحديث الملف README أو رسميًا مثل تحديث مستندات الواجهة أو الرسوم البيانية إذا تطورت البنية).
• لقد عرضت الميزة على الفريق أو أصحاب المصلحة لإثبات أنها تعمل بشكل شامل. للوهلة الأولى، قد يبدو هذا بمثابة الكثير من المربعات التي يجب وضع علامة عليها، ولكنه يضمن بقاء الجودة عالية وعدم إغفال أي شيء. من الأفضل اكتشاف الخلل بعد دقائق أو ساعات من تقديمه، بدلاً من اكتشافه بعد أشهر أثناء الاختبار النهائي.
• التوثيق المستمر: هناك نصيحة رائعة تستخدمها بعض الفرق: احتفظ بمخططات البنية هذه (من المرحلة 4. 1) متزامنة مع الكود. إذا كنت تستخدم “المخططات كرمز” (مثل PlantUML أو Mermaid)، فيمكنك تخزين مصدر المخطط في مستودعك وحتى تحديثه كلما تغيرت الأمور. على سبيل المثال، إذا تغير التصميم (ربما قمت بإضافة خدمة صغيرة جديدة في السحابة أو مستشعر جديد على الجهاز)، فقم بتحديث الرسم التخطيطي وأعد إنشائه. حتى أن بعض إعدادات CI تفشل في الإنشاء إذا قمت بتغيير التعليمات البرمجية التي تؤثر على البنية ولكنك لم تقم بتحديث المخططات. بهذه الطريقة تكون وثائقك محدثة دائمًا. لا مزيد من صفحات الويكي القديمة التي تصف نسخة من النظام لم تعد موجودة!
• عروض توضيحية منتظمة: في نهاية كل سباق سريع (أو حتى كل أسبوع)، من الرائع أن تحصل على عرض توضيحي سريع. أظهر للفريق (وغيرهم من أصحاب المصلحة) ما الذي ينجح.”انظر، الجهاز يرسل الآن البيانات ويمكننا رؤيتها على لوحة المعلومات هذه!”تخلق هذه العروض التوضيحية إحساسًا بالتقدم وتفرض أيضًا انضباط التكامل - لا يمكنك عرض شيء ما ما لم تعمل الأجزاء معًا بالفعل. إنه لأمر مدهش كم هو محفز أن يكون لديك دائمًا شيء تعرضه، حتى لو كان صغيرًا. كما أنه يزيل مشكلات التكامل مبكرًا (من الأفضل اكتشاف عدم التطابق بين firmware والسحابة في الأسبوع الرابع منه في الأسبوع 14).

لتلخيص المرحلة 4: يتعلق الأمر كله بـ التطوير التكراري والاختبار المستمر. بحلول نهاية الأمر (على الأرجح بعد عدة جولات)، يجب أن يكون لديك برنامج ثابت مكتمل الميزات ومختبر، ونظام سحابي مكتمل الميزات ومختبر - بشكل أساسي الجانب البرمجي الكامل لمنتجك جاهز للتشغيل. والأهم من ذلك، بفضل العمل التكراري، سيكون لديك العديد من الفرص للتعديل والتحسين على طول الطريق، بدلاً من المراهنة على كل ذلك على تكامل واحد كبير في النهاية. وهذا يقلل من المخاطر ويجعل التطوير أكثر قابلية للتنبؤ (وبصراحة، أكثر متعة - لأنك ترى منتجك ينبض بالحياة خطوة بخطوة 🎉).## المرحلة 5: بوابات التكامل (التأكد من أن كل شيء يسير على ما يرام)

لديك الآن نماذج أولية للأجهزة (المرحلة 3) وبنيات البرامج التكرارية (المرحلة 4). تدور المرحلة الخامسة حول دمج كل شيء والتحقق عند المعالم الرئيسية من أن النظام يعمل بشكل شامل. نطلق على هذه المعالم بوابات التكامل - فكر فيها على أنها “رؤساء نقاط التفتيش” في لعبة فيديو. لن تنتقل إلى المستوى التالي حتى تثبت قدرات معينة عند كل بوابة. إنه مزيج من الإثارة والقلق عندما تجمع بين الأجهزة + firmware + السحابة وتراقب الشرر (نأمل أن يكون ذلك مجازيًا فقط!).

فيما يلي بوابات التكامل النموذجية في مشروع منتج IoT:

• بوابة الإظهار: هذا هو أول اختبار تكامل أساسي مع الأجهزة الفعلية. الهدف عند هذه البوابة متواضع جدًا: _هل تقوم وحدة MCU الموجودة على اللوحة الخاصة بنا بالتمهيد وتشغيل التعليمات البرمجية؟ _ ستتحقق من أنه يمكنك تثبيت البرنامج الثابت على الجهاز، وأنه يبدأ في التنفيذ (على سبيل المثال، مؤشر LED وامض بسيط أو رسالة تسلسلية مثل “Hello, World” تؤكد الحياة). تأكد أيضًا من أن الجهاز يمكنه القيام بأشياء بدائية مثل قراءة مستوى البطارية أو جهد الإمداد الخاص به، والتواصل مع وحدة التحكم أو المسجل. في الأساس، المريض على قيد الحياة.🩺 يتم اجتياز هذه البوابة عندما تتأكد من أن اللوحة ليست قالبًا من الطوب وأن أجهزتك الأساسية (الطاقة والساعة والإدخال/الإخراج الأساسي) وسلسلة الأدوات (المبرمج، وما إلى ذلك) تعمل.
• بوابة مسار البيانات: نقوم الآن باختبار السبب الأساسي لوجود هذا النظام بأكمله: وهو نقل بيانات المستشعر من الجهاز إلى السحابة. عند بوابة مسار البيانات، يجب عليك إثبات أن قيم المستشعر تظهر في قاعدة البيانات السحابية أو الخادم كما هو متوقع. على سبيل المثال، إذا كان جهاز استشعار لدرجة الحرارة، فإنك تقوم بتشغيل بعض القراءات على الجهاز، ويتم نقلها عبر الشبكة (سواء كانت BLE، أو Wi-Fi، أو شبكة خلوية، وما إلى ذلك)، وينتهي بها الأمر في التخزين السحابي أو التطبيق. ستتحقق من أن البيانات تجعل الرحلة سليمة وفي الوقت المناسب - فالقراءات لها الطابع الزمني الصحيح، وأنها ضمن النطاقات والدقة المتوقعة، ويتم استيفاء معدل التحديث (على سبيل المثال كل 10 دقائق). إنها في الأساس شريحة رأسية كاملة من الوظائف: المستشعر -> الجهاز -> الشبكة -> السحابة -> قاعدة البيانات. عادةً ما يعني اجتياز هذه البوابة عملية نقل البيانات من طرف إلى طرف من الناحية العملية، وليس من الناحية النظرية فقط. إنه إنجاز كبير لأنه يثبت أن التصميم والتنفيذ الخاصين بك يقدمان القيمة الأساسية (جمع البيانات ونقلها).
• بوابة قصة المستخدم: هنا نخطو خطوة أخرى نحو ما سيختبره المستخدم النهائي الحقيقي. لا يكفي أن تصل البيانات إلى قاعدة البيانات؛هل يمكن للمستخدم الاستفادة منه فعليًا؟ عند بوابة قصة المستخدم، يمكنك دمج الواجهة الأمامية (مثل تطبيق الهاتف المحمول أو لوحة معلومات الويب) وإظهار سيناريو يواجه المستخدم حقيقيًا. على سبيل المثال، يفتح المستخدم التطبيق ويرى قراءة درجة الحرارة المباشرة من الجهاز، ربما بالإضافة إلى رسم بياني للتاريخ لآخر 24 ساعة. أو ربما يتلقى المستخدم تنبيهًا من النظام عند خروج القراءة عن النطاق المقبول. باختصار، أصبح المنتج الآن قابلاً للعرض بطريقة ذات معنى. غالبًا ما تكون هذه هي النقطة التي يمكنك فيها تسليم الجهاز إلى أحد أصحاب المصلحة أو أحد مختبري النسخة التجريبية الودودين ويمكنهم استخدامه بطريقة أساسية ولكن حقيقية. عند اجتياز هذه البوابة، تكون قد قمت بشكل أساسي بتوصيل جميع النقاط: تعمل الأجهزة وfirmware والواجهة الخلفية السحابية وواجهة المستخدم معًا بشكل جيد.- بوابة تجميد التصميم: هذا نوع مختلف قليلاً من البوابة - لا يتعلق الأمر بإظهار قدرة جديدة بقدر ما يتعلق بتأمين الأشياء حتى النهاية. في هذه المرحلة، من المحتمل أنك قد قمت بتكرار واحد أو أكثر من أجهزتك (ربما تنتقل من EVT - اختبار التحقق من الصحة الهندسية - النموذج الأولي إلى DVT - اختبار التحقق من صحة التصميم - الإصدار).تجميد التصميم يعني أنك تعتقد أن التصميم جيد بما يكفي لعدم إجراء أي تغييرات أخرى بطرق من شأنها أن تؤثر على الإنتاج. تم تجميد تصميم الأجهزة (أنت جاهز لطلب الإصدار النهائي من مركبات PCB والالتزام بالأدوات الخاصة بالمرفقات، وما إلى ذلك)، والبرنامج الثابت مكتمل بالميزات (لا توجد ميزات جديدة، فقط إصلاحات للأخطاء من هنا فصاعدًا). إنه حدث هام لأنه بمجرد تجميد التصميم، فإن أي تغييرات تكون مكلفة للغاية (فكر: تحديث تصميم اللوحة بعد أن طلبت 10000 وحدة - ليس متعة). في كثير من الأحيان، قبل الإعلان عن تجميد التصميم، تقوم الفرق بإجراء مراجعة أو جولة اختبار شاملة للتأكد من أن كل شيء يلبي المتطلبات. بعد هذه النقطة، تنتقل إلى مرحلة التحقق وإصدار الشهادات وتكثيف التصنيع بالتصميم كما هو.

لإدارة هذه البوابات، غالبًا ما تعقد الفرق اجتماعات مراجعة الأحداث المهمة. سيكون لديهم قائمة مرجعية (هل تتذكر متطلبات المرحلة الأولى وطرق التحقق الخاصة بهم؟) وسيقومون بالاطلاع على المتطلبات التي تم استيفاؤها. ومن المتوقع استيفاء متطلبات معينة لكل بوابة. على سبيل المثال، من خلال بوابة مسار البيانات، يجب التحقق من جميع المتطلبات المتعلقة بنقل البيانات وقراءة أجهزة الاستشعار على أنها “تم استيفاؤها في الاختبار”. إذا لم يتم استيفاء شيء ما، فإنه يصبح بند عمل - والأهم من ذلك، لا تتجاهله لإصلاحه لاحقًا. يمكنك تتبعه وإصلاحه _ قبل _ المضي قدمًا. يمنع هذا الانضباط تراكم المشكلات في النهاية. من المغري أحيانًا أن تقول “أوه، هذا الجزء لم يعمل بعد، لكننا سنتعامل معه لاحقًا”. مقاومة هذا الإغراء على البوابات! تشبه كل بوابة تكامل شبكة أمان، حيث يمكنها اكتشاف المشكلات عندما يكون من السهل إصلاحها (أي الآن، وليس عندما تكون في حالة ذعر قبل الإطلاق).

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

ونعم، تعامل مع اجتياز كل بوابة كفرصة احتفال صغيرة 🎉 - فهذه الانتصارات الصغيرة هي التي تحافظ على تحفيز الفريق في رحلة طويلة. ربما فقط تأجيل الشمبانيا حتى يتم تأكيد تجميد التصميم.😉

المرحلة 6: التحقق والتحقق (هل بنينا الشيء الصحيح، وهل يعمل بشكل صحيح؟)

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

دعونا نقسمها إلى طبقات النظام، لأن كل منها يتطلب أساليب اختبار مختلفة:

• التحقق من الأجهزة: نحتاج إلى التأكد من أن الأجهزة الفعلية بالجهاز تعمل على النحو المنشود. وهذا ينطوي على:
• الاختبار الوظيفي للأجهزة: يتم إجراؤه غالبًا باستخدام أداة اختبار أو أداة اختبار - وهو في الأساس إعداد يمكنك من خلاله توصيل الجهاز أو الضغط عليه على دبابيس pogo، ويقوم الكمبيوتر بتشغيل قائمة عمليات الفحص. على سبيل المثال، قد يتم التحقق من أن كل مستشعر يُرجع قراءات صحيحة، وأن دبابيس الإدخال/الإخراج الخاصة بMCU تعمل، وأن شاحن البطارية يشحن، وما إلى ذلك. يمكن أن يكون هذا هو نفس الإعداد المستخدم لاحقًا في التصنيع لاختبار نهاية الخط.- اختبار الإجهاد والموثوقية: يتضمن ذلك أشياء مثل HALT (اختبار الحياة المتسارع للغاية) حيث تقوم بدفع الجهاز إلى أقصى الحدود (درجة حرارة عالية/منخفضة، اهتزاز، طفرات كهربائية) لمعرفة ما الذي ينكسر أولاً. على سبيل المثال، هل يتم إعادة تشغيل الجهاز عند -20 درجة مئوية؟ هل صدمة السقوط تدق شيئًا فضفاضًا؟ من الأفضل اكتشافها في المختبر بدلاً من الميدان.
• الفحص المسبق البيئي والتنظيمي: إذا كنت بحاجة إلى اجتياز شهادات رسمية (اختبارات EMC، ومناعة ESD، وما إلى ذلك)، فعادةً ما تقوم بإجراء فحص مسبق الآن لاكتشاف أي مشكلات. على سبيل المثال، ضع الجهاز في غرفة كاتمة للصدى وقم بقياس الانبعاثات الكهرومغناطيسية أثناء تشغيله - هل هي أقل من الحدود القانونية (لجنة الاتصالات الفيدرالية، CE، وما إلى ذلك)؟ إذا لم يكن الأمر كذلك، فقد تحتاج إلى تعديل التصميم (إضافة درع، وتصفية الخطوط المزعجة). يمكنك صعق الجهاز بالتفريغ الكهروستاتيكي لمعرفة ما إذا كان سيتم إعادة ضبطه أو تحمل الصدمة. كل هذا لضمان حصولك على الشهادة النهائية (المرحلة 7)، لن تكون هناك مفاجآت.
• المعيار مقابل المواصفات: يتم اختبار الأجهزة وفقًا لـ المواصفات الواردة في أوراق البيانات ومتطلباتك الخاصة. إذا كان من المفترض أن تكون دقة المستشعر ±0. 5 درجة مئوية، فاختبره عبر نطاق من درجات الحرارة باستخدام أداة مرجعية للتأكيد. إذا كان من المفترض أن يكون عمر البطارية عامًا واحدًا بعد الشحن، فقم بإجراء اختبارات استهلاك الطاقة لتقدير ما إذا كان ذلك صحيحًا في ظل سيناريوهات مختلفة. في الأساس، يعني “التحقق” التحقق من المنتج ** الذي يلبي مواصفات ومتطلبات التصميم **.
• التحقق من firmware (البرامج المضمنة): اختبار الكود الموجود على الجهاز:
• اختبارات الوحدة: تمامًا مثل أي برنامج، (نأمل) أن يكون لديك اختبارات وحدة للبرامج الثابتة لديك. قد تستخدم هذه أطر عمل مثل Unity (إطار عمل اختبار الوحدة لـ C، وليس محرك اللعبة!) أو CppUTest أو GoogleTest للتعليمات البرمجية المضمنة لـ C++. يتم إجراء اختبارات الوحدة على جهاز كمبيوتر مضيف أو في المحاكاة للتحقق من أن كل وظيفة أو وحدة تتصرف بشكل صحيح بمعزل عن غيرها.
• اختبارات التكامل (firmware): بالإضافة إلى الوحدات، يمكنك اختبار كيفية عمل الوحدات معًا على الجهاز الفعلي. ربما تكتب اختبارًا يتم تشغيله على الجهاز لقراءة المستشعر ومقارنته بمدخل معروف (قد تقوم بتغذية جهد معين لمدخل المستشعر ومعرفة ما إذا كانت القراءة متطابقة).
• التحليل الثابت: أدوات تعمل على تحليل التعليمات البرمجية الخاصة بك بحثًا عن الأخطاء المحتملة دون تشغيلها. يمكن أن تكتشف هذه الأشياء مثل تجاوز سعة المخزن المؤقت، أو إلغاء مرجعيات المؤشر الفارغة، أو انتهاكات أفضل الممارسات. إذا اتبعت MISRA-C أو ما شابه، فسوف تقوم بتشغيل محلل ثابت للتأكد من أنك لم تنتهك أيًا من هذه القواعد. الهدف هو الحصول على 0 تحذيرات حرجة (لا توجد مشكلات واضحة تتعلق بسلامة الذاكرة أو التزامن).
• تحليل التغطية: يمكنك قياس مقدار التعليمات البرمجية التي تم تنفيذها من خلال اختباراتك (التغطية). يهدف المعيار الشائع إلى >= تغطية التعليمات البرمجية بنسبة 80% في اختبارات الوحدة، مما يعني أنه تم اختبار غالبية التعليمات البرمجية الخاصة بك. التغطية ليست كل شيء (100% لا تضمن خلوها من الأخطاء)، ولكن إذا كانت لديك تغطية بنسبة 20% فقط، فمن المؤكد أنك فاتتك الكثير من الاختبارات.
• اختبار التشويش والضغط: بالنسبة للبرامج الثابتة، خاصة إذا كانت ذات حالة معقدة أو متزامنة (سلاسل متعددة)، يمكنك إجراء أشياء مثل التشويش في حالة السباق أو اختبارات طويلة المدة. على سبيل المثال، قم بتشغيل الجهاز لمدة أسبوع متواصل لمعرفة ما إذا كان أي تسرب للذاكرة يتسبب في حدوث عطل، أو قم بقصفه بإدخالات سريعة لمعرفة ما إذا كان قد وصل إلى حالة سيئة.
• اختبار البرامج السحابية/API: على الجانب السحابي، يكون الاختبار عادة أكثر وضوحًا (نظرًا لأن لدينا أدوات وبيئات غير محدودة تقريبًا):
• اختبارات API التلقائية: باستخدام أدوات مثل Postman أو Newman، يمكنك كتابة نصوص اختبارية لواجهة REST API أو MQTT. على سبيل المثال، أرسل حزمة بيانات جهاز تمت محاكاتها إلى نقطة النهاية السحابية لديك - هل تستجيب بشكل صحيح؟ الاستعلام عن البيانات عبر API – هل يمكنك الحصول على البيانات الصحيحة بالتنسيق الصحيح؟- اختبار الأمان: قم بإجراء فحص أمان OWASP أو ما شابه ذلك على نقاط نهاية الويب لديك. التحقق من وجود نقاط الضعف الشائعة (حقن SQL، XSS، وما إلى ذلك). إذا كانت بيانات IoT حساسة، فتأكد من أن أشياء مثل المصادقة والتحكم في الوصول تعمل بشكل صحيح (لا توجد أبواب خلفية خادعة). من الممكن تعيين مدقق أمني أو استخدام أدوات فحص الثغرات الأمنية الآلية.
• اختبار التحميل: إذا كنت تتوقع اتصال 1000 جهاز، فحاول محاكاة حركة المرور على 2000 جهاز لمعرفة ما سيحدث. الهدف هو التأكد من قدرة نظامك على التعامل مع ما لا يقل عن 2× الحمل الأقصى المتوقع. قياس أوقات الاستجابة - على سبيل المثال، يجب معالجة 95% من الطلبات في أقل من 150 مللي ثانية (أو ما هو مقبول لتطبيقك). إذا بدأ النظام في التعطل، فقد تحتاج إلى تحسين التعليمات البرمجية أو زيادة موارد الخادم. من الأفضل العثور على نقطة الانهيار الآن بدلاً من يوم الإطلاق.
• اختبار تجربة المستخدم: لا تنس تجربة المستخدم - اطلب من بعض المستخدمين اختبار واجهة التطبيق. هل تعرض الرسوم البيانية البيانات الصحيحة؟ هل واجهة المستخدم بديهية؟ في حين أن هذا قد يكون بمثابة التحقق من الصحة (التأكد من أنه يحل احتياجات المستخدم)، إلا أنه لا يزال مجال اختبار مهم.
• التحقق من صحة النظام: أخيرًا، الصورة الكبيرة: هل يلبي النظام بأكمله (الأجهزة + firmware + السحابة + تطبيق المستخدم) المتطلبات الأصلية ويحل المشكلة المقصودة؟
• تتبع المتطلبات واختبارها: هل تتذكر مستند المتطلبات من المرحلة الأولى؟ يمكنك الآن مراجعة كل المتطلبات والتأكد من وجود اختبار أو ملاحظة تثبت استيفاءها. عادةً، يمكنك الاحتفاظ بمصفوفة مصفوفة تتبع المتطلبات - وهو مصطلح فاخر لجدول يربط كل متطلب بحالة الاختبار أو الحالات التي تتحقق منه. على سبيل المثال، قد يرجع متطلب “يجب أن يعمل الجهاز لمدة عام واحد على البطارية” إلى عملية حسابية أو نتيجة اختبار من قياس الطاقة. مطلب “يجب أن يرسل النظام تنبيهًا إذا تجاوزت درجة الحرارة الحد الأدنى” يتتبع اختبارًا حيث وضعوا الجهاز في غرفة ساخنة ولاحظوا تنبيهًا في التطبيق.
• التجارب التجريبية: إحدى خطوات التحقق الشائعة هي إجراء اختبار تجريبي أو تجربة ميدانية. يمكنك نشر عدد قليل من الوحدات في الميدان (ربما مع مستخدمين ودودين أو أشخاص داخليين) والسماح لهم باستخدامها في بيئة حقيقية لعدة أسابيع. يكشف هذا غالبًا عن أشياء لن تتمكن من اكتشافها في الاختبارات المعملية - ربما يحتاج الجهاز إلى آلية تركيب أفضل، أو يجد المستخدمون أن عملية الإعداد مربكة. إنها تعليقات قيمة للغاية للتحقق من أن المنتج يحل المشكلة فعليًا وأنه سهل الاستخدام بدرجة كافية.
• معايير النجاح/الفشل: أنت تضع معايير عندما يمكنك أن تقول بثقة “لقد انتهينا، وقد نجحنا”. قد يكون هذا شيئًا مثل: تم اجتياز 95% من جميع حالات الاختبار، وبالنسبة لـ 5% المتبقية، تكون أي حالات فشل طفيفة أو لها حلول بديلة مقبولة. بالإضافة إلى ذلك، لا توجد أخطاء خطيرة من الدرجة 1 مفتوحة - مما يعني أنه لا توجد مشكلات معروفة في إيقاف العرض مثل “اشتعال النيران في الجهاز إذا تم توصيله بشكل عكسي” أو “يتعطل الخادم كل ساعة”. إذا كانت هناك أخطاء في Sev 1، فلن يتم التشغيل حتى يتم إصلاحها أو تخفيفها.

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

منظور آخر: التحقق والتحقق يطرح سؤالين بشكل أساسي:

• التحقق: “هل بنينا الشيء بشكل صحيح؟“(أي هل يتوافق مع التصميم والمتطلبات؟)
• التحقق: “هل بنينا الشيء الصحيح؟“(أي هل يحل المشكلة الأصلية بالفعل ويجعل المستخدمين سعداء؟)عندما تتمكن من الإجابة على كليهما بـ نعم! – تصبح جاهزًا للمرحلة التالية.

المرحلة 7: الامتثال والاعتماد ونقل التصنيع

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

الجوانب الرئيسية لهذه المرحلة:

• الامتثال التنظيمي والاعتماد: اعتمادًا على ما يفعله منتجك والمكان الذي تريد بيعه فيه، غالبًا ما تكون الموافقات التنظيمية مطلوبة. على سبيل المثال، إذا كان جهازك يستخدم ترددات الراديو (Wi-Fi، Bluetooth، الخلوية، وما إلى ذلك)، فستحتاج على الأرجح إلى شهادة من هيئات مثل FCC (لجنة الاتصالات الفيدرالية) في الولايات المتحدة الأمريكية، وCE/ETSI RED (توجيه معدات الراديو) في أوروبا، من بين جهات أخرى. يضمن ذلك عدم تداخل جهازك مع الأجهزة الأخرى وبقائه ضمن حدود الانبعاثات القانونية. قد تحتاج إلى إرسال وحدات إلى مختبرات معتمدة للاختبار. هناك أيضًا اختبارات عامة EMC (التوافق الكهرومغناطيسي) - حتى لو لم تكن لاسلكية، يجب ألا ينبعث أي جهاز إلكتروني الكثير من الضوضاء الكهرومغناطيسية ويجب أن يتحمل قدرًا معينًا من الضوضاء البيئية. إذا كان منتجك سيتم بيعه في بلدان مختلفة، فقد تحتاج إلى شهادات متعددة (FCC، CE، UKCA للمملكة المتحدة، IC لكندا، وما إلى ذلك). إنه نوع من العمل الورقي والتمرين اللوجستي - ملء النماذج، ودفع الرسوم، وشحن الأجهزة إلى المختبرات - ولكنه إلزامي.نصيحة احترافية: نأمل أن تكون قد أجريت بالفعل عمليات فحص مسبقة في المرحلة 6؛إن الدخول في اختبار رسمي دون اختبار مسبق هو مقامرة. وأيضًا، إذا تم تصميم جهازك باستخدام وحدات معتمدة بالفعل (على سبيل المثال، وحدة راديو معتمدة مسبقًا)، فيمكن أن يؤدي ذلك إلى تبسيط أو تقليل الاختبارات المطلوبة.
• شهادات السلامة: إذا كان منتجك متصلاً بمصدر الطاقة أو كان يشبه جهازًا يمكن ارتداؤه أو يحتوي على بطارية، فهناك معايير أمان يجب أخذها في الاعتبار. بالنسبة للإلكترونيات، قد يتم تطبيق IEC 62368 (لسلامة المعدات الصوتية/البصرية/معدات تكنولوجيا المعلومات)، أو IEC 61010 لمعدات المختبرات، وما إلى ذلك. إذا كان جهازك يتحكم في الآلات أو يمكن أن يؤثر على سلامة الأشخاص (مثل جهاز استشعار في آلة صناعية)، فقد يتم تطبيق معايير مثل ISO 13849 (السلامة الوظيفية للآلات). غالبًا ما تتضمن شهادة السلامة إثبات أشياء مثل عدم وجود خطر حدوث صدمة كهربائية، وعدم ارتفاع درجة حرارة الجهاز والتسبب في نشوب حريق، وحماية أي أجزاء متحركة بشكل صحيح، وما إلى ذلك. قد يتطلب هذا تعديلات في التصميم مثل إضافة الصمامات، وقطع الحرارة، وفجوات العزل في PCB، وملصقات التحذير - جميع عناصر السلامة الكلاسيكية.
• الشهادات البيئية والشهادات الأخرى: ربما يحتاج جهازك إلى تصنيف IP (مقاومة الماء/الغبار مثل IP67)، أو الامتثال للوائح البيئية (RoHS للمواد الخطرة، وWEEE للتخلص من النفايات). لقد حان الوقت لفرز تلك الأشياء أيضًا. إذا كانت تعمل بالبطارية، فيجب مراعاة لوائح الشحن الخاصة ببطاريات الليثيوم. إذا كان سيتم استخدامه في السياقات الطبية أو السيارات، فقد يتم تطبيق مجموعات جديدة تمامًا من المعايير (تلك المجالات لها شهاداتها الصارمة الخاصة).
• تسليم التصنيع: أثناء استمرار الحصول على الشهادة، يمكنك أيضًا الاستعداد للتصنيع. هذا يعني:
• الانتهاء من قائمة المواد الخاصة بك مع الشركات المصنعة/أرقام الأجزاء الفعلية والتأكد من أن لديك مصادر لكل منها (والنسخ الاحتياطية للأجزاء الرئيسية إن أمكن).
• العمل مع ** CM (الشركة المصنعة للعقد) ** أو فريق الإنتاج الخاص بك لإعداد خط التجميع. سيحتاجون إلى أشياء مثل ملفات الانتقاء والمكان لتجميع PCB، وإجراء الاختبار لكل وحدة.- تصميم تركيبات اختبار الإنتاج (إذا لم تكن قد تم ذلك بالفعل). هل تتذكر أننا تحدثنا عن أدوات الاختبار؟ في التصنيع، سيكون لديك محطة اختبار حيث يتم تحديث كل جهاز بأحدث firmware (غالبًا ما تسمى صورة البرنامج الثابت “الذهبية”، وهي النسخة النهائية التي تم التحقق من صحتها)، ويتم اختبارها للتأكد من أن كل شيء يعمل. قد تتضمن هذه التركيبة توصيل دبابيس بوجو بنقاط اختبار على لوحة الدوائر المطبوعة لديك، أو اختبار وظيفي حيث يضغط الروبوت على الأزرار ويقرأ المستشعرات، اعتمادًا على التعقيد. قد يكون لديك مراحل متعددة: على سبيل المثال، اختبار ICT أساسي (اختبار داخل الدائرة) لفحص مجموعة PCB، ثم اختبار وظيفي بعد التجميع، وما إلى ذلك.
• إعداد التزويد للاتصال السحابي. إذا كان كل جهاز يحتاج إلى مفتاح أو شهادة فريدة للاتصال بسحابتك بشكل آمن، فيجب عليك معرفة كيفية إدخالها أثناء الإنتاج. في بعض الأحيان يتم ذلك في خطوة تثبيت الاختبار - قد يقوم الجهاز بإنشاء زوج مفاتيح وتقوم أنت بتسجيل المفتاح العام في قاعدة البيانات الخاصة بك، أو تقوم بإصدار شهادة فريدة قمت بإعدادها. يعد الأمان أمرًا بالغ الأهمية هنا: فأنت تريد مسارًا حتى يتم إنشاء الأجهزة ببيانات اعتماد مناسبة ولا تكون هناك فرصة للاستنساخ أو التلاعب. قد يتضمن ذلك العمل مع فريق السحابة الخاص بك للحصول على API (API) لتوفير معرفات الأجهزة الجديدة.
• إعداد وثائق التصنيع: رسومات التجميع، ومعايير الفحص (مثل الشكل الذي تبدو عليه وصلة اللحام المقبولة مقابل الوصلة المرفوضة)، وخطة لأخذ عينات مراقبة الجودة (ربما تقوم باختبار كامل للوحدات بنسبة 100%، أو إذا كانت كبيرة الحجم، يمكنك اختبار عينة من كل دفعة بعمق).
• تشغيل تجريبي للإنتاج: تقوم العديد من الفرق بإجراء تشغيل تجريبي صغير (على سبيل المثال، 100 وحدة) مع الشركة المصنعة لحل أي مشاكل في الإنتاج. من الأفضل أن تكتشف في مجموعة مكونة من 100 قطعة أن آلة التجميع كانت تعيد المكثف إلى الخلف بدلاً من معرفة مجموعة مكونة من 10000 قطعة. يمكن أيضًا استخدام الوحدات التجريبية في اختبارات الشهادات النهائية، أو تجارب العملاء التجريبية، أو الاختبارات الداخلية. إنه جسر بين النموذج الأولي والإنتاج الكامل.
• الخدمات اللوجستية وسلسلة التوريد: ضع في اعتبارك أيضًا أشياء مثل التعبئة والتغليف والشحن والتوزيع. هل يحتاج منتجك إلى صندوق ذو مظهر رائع؟ أي إدخالات أو أدلة خاصة (وهل تحتاج هذه الأدلة إلى الامتثال الخاص بها، مثل المعلومات التنظيمية)؟ وكيف ستتعامل مع الإصلاحات/الإرجاعات في حالة وجود خلل ما؟ على الرغم من أن هذا قد يتحول إلى مجال الأعمال، إلا أنه من الجيد أن تشارك كمطور منتج، بحيث يدعم تصميم الجهاز تتبع الرقم التسلسلي بسهولة، وما إلى ذلك (على سبيل المثال، تأكد من أن كل جهاز يحتوي على ملصق فريد أو معرف محفور لتحديد هويته لاحقًا).

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

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

المرحلة 8: الإطلاق والتشغيل والصيانة (الحياة بعد زر الإطلاق)

يوم الإطلاق! 🚀 لقد وصلت إلى هذا الحد - من الفكرة إلى منتج IoT مُصنّع ومعتمد. خذ لحظة للاحتفال – هذا إنجاز كبير. لكن الرحلة لا تنتهي عند شحن الوحدات الأولى. من نواحٍ عديدة، تدور المرحلة 8 حول العمر المستمر لمنتج IoT الخاص بك بمجرد طرحه في السوق. يتضمن ذلك كيفية نشر التحديثات، ومراقبة أسطول الأجهزة، ودعم المستخدمين، وفي النهاية، كيفية إيقاف المنتج بأمان عندما يحين الوقت. يتطلب منتج IoT الناجح بعض TLC (Tender Loving Care) بعد الإطلاق للحفاظ على سير الأمور بسلاسة وإسعاد العملاء.

المكونات الرئيسية لهذه المرحلة:

• تحديثات عبر الهواء (التحديثات عبر الأثير): على عكس أجهزة المدرسة القديمة، غالبًا ما يُتوقع أن تتحسن منتجات IoT بمرور الوقت من خلال تحديثات البرامج - أو على الأقل تكون قابلة للإصلاح في حالة اكتشاف خطأ. للقيام بذلك، تحتاج إلى خط أنابيب تحديث عبر الهواء قوي. وهذا يعني وجود بنية تحتية يمكنها تقديم تحديثات firmware عن بُعد للأجهزة الموجودة في الميدان. من الضروري تنفيذ ذلك بشكل آمن: يجب أن تكون التحديثات موقعة بشكل مشفر (بحيث تقبل الأجهزة فقط التحديثات الأصلية منك، وليس التحديثات الضارة) ومن الناحية المثالية مشفرة أثناء النقل. أيضًا، صمم عملية التحديث لتكون موثوقة وآمنة من الفشل - على سبيل المثال، استخدم أقسام firmware المزدوجة على الجهاز حتى يتمكن من العودة إلى إصدار جيد معروف في حالة فشل التحديث (لا أحد يريد جهازًا “معطلًا” لا يمكنه استرداده بسبب مقاطعة التحديث). ستحتاج أيضًا إلى إجراء عمليات نشر مرحلية للتحديثات: بدلاً من تحديث 10000 جهاز مرة واحدة (وإذا كان هناك خطأ، فكل الـ 10000 جهاز به 🙈)، ربما قم بتحديث 100 جهاز أولاً، وراقبها لمدة يوم أو يومين، ثم 1000، ثم الباقي. بهذه الطريقة، إذا حدث خطأ ما، يمكنك اكتشافه مبكرًا ولا تتأثر سوى نسبة صغيرة من المستخدمين. امتلك دائمًا خطة التراجع: القدرة على إرسال firmware القديمة بسرعة إذا كان البرنامج الجديد به مشكلة خطيرة. في الأساس، OTA هي شبكة الأمان الخاصة بك وطريقتك لمواصلة إضافة القيمة (ميزات أو تحسينات جديدة) إلى المنتج دون استدعاء الأجهزة فعليًا.
• قابلية المراقبة والمراقبة: بمجرد توفر الأجهزة، ستحتاج إلى مراقبة كيفية سير الأمور. تنفيذ مراقبة الجهاز في السحابة الخاصة بك: يمكن للأجهزة تقديم تقارير دورية عن المقاييس الصحية (مستوى البطارية، واستخدام الذاكرة، وقوة الإشارة، وما إلى ذلك). قم بإعداد التنبيهات للحالات غير الطبيعية (على سبيل المثال، في حالة انقطاع اتصال الجهاز بالإنترنت لأكثر من ساعة، أو انخفاض مستوى البطارية إلى أقل من 10%، أو زيادة استخدام الذاكرة مما يشير إلى احتمال حدوث تسرب). على الجانب السحابي، راقب الخوادم وواجهات برمجة التطبيقات – استخدم السجلات ولوحات المعلومات والتنبيهات لأشياء مثل معدلات الخطأ أو الاستجابات البطيئة. تحتوي العديد من منصات IoT على لوحات معلومات لإدارة الأسطول، توضح عدد الأجهزة المتصلة وحالاتها وما إلى ذلك. يمكنك أيضًا توفير صفحة الحالة للمستخدمين (خاصة إذا كان هذا منتجًا مؤسسيًا أو استهلاكيًا) حتى يتمكنوا من معرفة ما إذا كانت الخدمة متاحة أو إذا كان هناك انقطاعات معروفة. بشكل أساسي، تعامل مع النظام باعتباره كائنًا حيًا يحتاج إلى الرعاية والتغذية: راقب أي عوائق وكن مستعدًا للاستجابة. أيضًا، خطط لـ التوسع: إذا نمت قاعدة المستخدمين الخاصة بك، فهل تستطيع البنية التحتية السحابية الخاصة بك التعامل معها؟ من الأفضل أن تقوم بتوسيع قاعدة بياناتك أو خوادمك بشكل استباقي بدلاً من إيقاف كل شيء يومًا ما لأنك أصبحت مشهورًا فجأة (مشكلة جيدة، ولكنها لا تزال مشكلة إذا لم تكن مستعدًا).
• دعم العملاء وحلقة الملاحظات: بمجرد أن يستخدم المستخدمون الحقيقيون المنتج، سيكون لديهم تعليقات - سواء كانت طلبات للأخطاء أو للميزات. قم بإعداد قنوات لالتقاط ذلك: ربما بريد إلكتروني للدعم أو نظام التذاكر، ومنتديات المجتمع، واستطلاعات المستخدمين، وما إلى ذلك. والأهم من ذلك، أن يكون لديك عملية لتغذية هذه المدخلات مرة أخرى في دورة التطوير الخاصة بك. في مصطلحات Agile، لا ينتهي العمل المتراكم أبدًا - ستبدأ الآن في إضافة إصدارات الصيانة أو ميزات التحسين بناءً على ما تعلمته من هذا المجال. على سبيل المثال، ربما يقول المستخدمون، “سيكون من الرائع أن يقوم الجهاز أيضًا بتسجيل البيانات عندما يكون غير متصل بالإنترنت ويتم تحميلها لاحقًا.”قد تصبح هذه ميزة في التحديث المستقبلي. أو تكتشف نمط استخدام معينًا لم يكن متوقعًا - يمكن لهذه الرؤية أن توجه عملية تكرار منتجك التالي أو منتج جديد تمامًا. راقب أيضًا أي أجهزة تم إرجاعها أو الإبلاغ عن خلل فيها - قم بإجراء تحليل السبب الجذري للأعطال في الميدان. هل كانت مجموعة من المكونات السيئة؟ عيب في التصميم يسبب التآكل؟ استخدم هذه المعلومات لتحسين التصنيع أو التصميم في المراجعة التالية.
• إصدارات الصيانة: على عكس التطوير الأولي، تكون هذه عادةً تحديثات أصغر (ربما كل بضعة أشهر أو حسب الحاجة) لإصلاح المشكلات أو إجراء تحسينات طفيفة. من الجيد تخطيط الموارد لهذا الغرض - حتى عندما ينتقل الفريق الأساسي إلى مشاريع جديدة، يجب أن يكون هناك شخص ما على سطح السفينة لصيانة المنتج الذي تم إطلاقه، على الأقل لفترة الدعم الموعودة.
• التخطيط لنهاية العمر (EOL): قد يبدو من الغريب التفكير في النهاية عند إطلاق المنتج للتو، ولكن الإدارة الجيدة للمنتج تأخذ في الاعتبار دورة الحياة الكاملة. في النهاية، سيصل منتج IoT الخاص بك إلى نهاية العمر الافتراضي (ربما بعد بضع سنوات). قد تصبح المكونات قديمة (قد تخرج وحدة MCU من الإنتاج خلال 5 سنوات، على سبيل المثال)، أو ستحل محلها نسخة جديدة من المنتج. من الحكمة أن يكون لديك خطة موسوعة الحياة:
• كيف سيتم إخطار العملاء عند إيقاف المنتج أو الخدمة؟
• هل ستوفر تصدير البيانات أو مسار الترحيل إذا تم إيقاف الخدمة السحابية، حتى يتمكن العملاء من استرداد بياناتهم التاريخية؟
• ما إرشادات إعادة التدوير أو التخلص الخاصة بالأجهزة (لا ينبغي إلقاء البطاريات والإلكترونيات في سلة المهملات فحسب - وبعض المناطق لديها قوانين بهذا الشأن)؟ ربما تقدم معلومات حول كيفية التخلص من الأجهزة أو إعادتها.
• في حالة انتهاء الخدمة السحابية، هل ستظل الأجهزة تعمل محليًا أم أنها ستصبح نفايات إلكترونية؟ (يمكن أن يكون تصميم وضع “التدهور السلس” بمثابة لمسة مدروسة - على سبيل المثال، لا يزال الجهاز يعمل بسعة محدودة دون الاتصال بالإنترنت.)
• تتبع تقادم المكونات: حافظ على علاقة مع موردي المكونات أو استخدم خدمة تنبهك عندما يكون الجزء هو NRND (غير موصى به للتصميمات الجديدة) أو EOL. إذا سمعت أنه سيتم إيقاف شريحة مهمة، فخطط لشراء آخر مرة أو تحديث تصميم لاستبدالها. ويضمن التخطيط لـ EOL أنه عندما يحين الوقت، يمكنك التعامل معها بمسؤولية والحفاظ على حسن النية مع المستخدمين. ليس هناك ما هو أسوأ من تعطيل الأجهزة التي دفع الناس ثمنها فجأة دون منحهم خيارات.

في المرحلة الثامنة، انتقلت من وضع التطوير إلى وضع العمليات. قد يغير فريقك تكوينه - ربما يقوم فريق عمليات أو فريق دعم مخصص بمراقبة النظام، بينما يبدأ فريق التطوير الأساسي المشروع التالي، ولكن مع بعض التداخل. إنه يشبه إلى حد ما تربية طفل: فالولادة (الانطلاق) حدث كبير، لكن الطفل يحتاج إلى رعاية طوال حياته. 😄 وبالمثل، سيحتاج منتج IoT الخاص بك إلى رعاية في الميدان.

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

ما هي القطعة الأثرية التي تأتي أولاً؟ (ترتيب العمليات)

ربما تتساءل، مع كل هذه المستندات والتصميمات المنتشرة حولك، بأي ترتيب يجب عليك إنشائها؟ هناك تسلسل منطقي (مع بعض التداخل) يساعد على تجنب هدر العمل:

• المتطلبات تأتي في المقام الأول - دائمًا. كما تم التأكيد عليه في المرحلة الأولى، عليك تحديد ما الذي تقوم ببنائه قبل القلق بشأن كيفية بنائه. من المغري للمهندسين المتحمسين البدء في البرمجة أو توصيل الأشياء على الفور، ولكن بدون متطلبات واضحة، قد ينتهي بك الأمر إلى بناء شيء “خاطئ تمامًا”. لذا، ابدأ بمستند متطلبات قوي أو تراكم حيث يوافق كل أصحاب المصلحة على احتياجات المنتج.
• تأتي بعد ذلك بنية النظام. بمجرد أن تعرف ما هو مطلوب، اكتشف تصميم الصورة الكبيرة الذي يمكنه تلبية تلك الاحتياجات (المرحلة 2). هذا هو المكان الذي تحدد فيه الحل الشامل (الكتل، وتدفقات البيانات، والخيارات التقنية الرئيسية). لا ينبغي عليك رسم مخططات تفصيلية للدوائر أو كتابة تعليمات برمجية فعلية حتى الآن؛بدلاً من ذلك، ركز على الغابة، وليس الأشجار. يمكن للهندسة المعمارية الجيدة أن تنقذك من الصداع الكبير من خلال الكشف عن التعقيدات والتحديات مبكرًا.
• التصميم التفصيلي المتوازي للأجهزة والبرامج: بعد تعيين بنية المستوى الأعلى (ومراجعتها/الموافقة عليها من قبل الفريق)، يمكنك البدء في تصميم الإلكترونيات التفصيلي وتصميم البرامج التفصيلي بالتوازي. يمكن للعاملين في الأجهزة البدء في التخطيطات/PCB (المرحلة 3)، ويمكن للعاملين في البرامج البدء في تصميم وحدات البرامج/مخططات UML بالتفصيل (المرحلة 4. 1) - طالما أنهم متزامنون بشأن الافتراضات (مثل كيفية التفاعل). ولا ينبغي لأي منهما العمل في صومعة. تساعد اجتماعات المزامنة المنتظمة أو مراجعات التصميم المشتركة هنا. على سبيل المثال، إذا قرر فريق الأجهزة تغيير جهاز استشعار إلى طراز مختلف، فيجب أن تعرف firmware ذلك لأنه قد يؤثر على برامج التشغيل؛إذا قرر فريق البرمجيات استخدام تنسيق معين للرسائل، فيجب أن يعرف الجهاز ذلك للتأكد من أن الجهاز يمكنه دعمه.
• حافظ على تناغم التصميمات مع التنفيذ: النصيحة العملية هي استخدام التحكم في الإصدار وCI لعناصر التصميم أيضًا، وليس فقط التعليمات البرمجية. إذا كان لديك مخطط نظام أو مواصفات واجهة، قم بتخزينه في Git. إذا قمت بتحديث التعليمات البرمجية بطريقة تغير النظام (على سبيل المثال، إضافة مكون جديد أو نوع رسالة جديد)، فقم بتحديث الرسم التخطيطي أو المواصفات في نفس الالتزام. تضمن لك هذه العادة ألا ينتهي بك الأمر إلى الحصول على مخططات جميلة لا يثق بها أحد لأنها قديمة. بالإضافة إلى ذلك، عندما ينضم أعضاء جدد في الفريق، يقومون بتحديث المستندات لمواكبة التطورات.
• لا تبالغ في التوثيق في وقت مبكر جدًا: قد يبدو الأمر متناقضًا بعد قول “قم بتوثيق كل شيء”، ولكن هناك حكمة في التفاصيل في الوقت المناسب. على سبيل المثال، قد يكون رسم مخطط انسيابي مفصل للغاية لوظيفة معينة للبرنامج الثابت قبل أشهر من تنفيذها مجهودًا ضائعًا إذا تغير التصميم بحلول ذلك الوقت. من الأفضل القيام بالتخطيط عالي المستوى مبكرًا، ولكن احفظ الوثائق التفصيلية (مثل مخططات تسلسل UML التفصيلية لروتين معين) عندما تكون على وشك العمل على هذا الجزء. القاعدة الأساسية الواردة في قواعد اللعبة ذهبية: _كلما كان تغيير شيء ما أكثر تكلفة في وقت لاحق، كان عليك اتخاذ قرار بشأنه مبكرًا. _ لذا، اتخذ قرارًا مبكرًا بشأن بنيتك الأساسية، ومكونات الأجهزة، وما إلى ذلك - فتغييرها باهظ التكلفة. لكن تفاصيل التنفيذ البسيطة أو الفروق الدقيقة في الميزات غير المهمة يمكن تحديدها لاحقًا عندما يكون لديك المزيد من المعلومات. في الأساس، ابدأ على نطاق واسع، ثم انتقل إلى نطاق ضيق مع تقدمك، وحافظ دائمًا على تحديث العناصر في ضوء التغييرات. بهذه الطريقة، يمكنك تنظيم فريقك وتجنب فخ “أوه، اعتقدت أنك ستفعل X، لكنني قمت ببناء Y”. إن التواصل والتزامن بين هذه المستندات والرسوم البيانية لا يقل أهمية عن إنشائها الأولي.

نصائح عملية لإدارة المشروع

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

• التخطيط ثنائي المسار: يتميز تطوير الأجهزة والبرامج بإيقاعات مختلفة - فقد تستغرق الأجهزة وقتًا طويلاً لتصنيع PCB، في حين يمكن للبرامج تشغيل الميزات أسبوعيًا. لإدارة ذلك، حافظ على مسارين متوازيين للمشروع (على سبيل المثال، في خطة مشروعك أو لوحة Agile، لديك مسارات منفصلة أو أقسام للأجهزة والبرامج). وقم بتنسيقها مع نقاط التزامن عند بوابات التكامل. بهذه الطريقة، يعرف فريق الأجهزة ما يفعله فريق البرامج والعكس صحيح، لكن يمكنهم تحسين سير العمل الخاص بهم. على سبيل المثال، قد تخطط أنه بحلول وقت وصول النماذج الأولية (المخطط الزمني للأجهزة)، سيكون البرنامج الثابت جاهزًا لاختبار الوظائف الأساسية (المخطط الزمني للبرنامج). ويمنع أحد الجانبين من أن يصبح عنق الزجاجة للآخر.
• تقليص المخاطر: في البداية (وطوال المشروع)، احتفظ بسجل أو لوحة للمخاطر. قم بإدراج الأشياء التي يمكن أن تسوء أو غير مؤكدة - عدم وصول المكونات الرئيسية في الوقت المحدد، أو عدم جاهزية API الشريكة، أو جزء من التكنولوجيا غير مثبت، وما إلى ذلك. قم بمراجعة هذه القائمة كل أسبوع أو أسبوعين مع الفريق. هل قمنا بتخفيف أي مخاطر؟ (على سبيل المثال، العثور على مصدر ثانٍ لهذا المكون، أو إنشاء نموذج أولي لاختبار هذا المفهوم). وهذا يحول الخوف المجرد من “المشاكل غير المعروفة” إلى عناصر ملموسة تديرها بنشاط. هناك شعور مُرضٍ برؤية المخاطر تتقاعد مع تقدمك. وإذا ظهرت جديدة (سوف تظهر)، يمكنك اكتشافها مبكرًا. من الأفضل أن تقول “لقد توقعنا أن تكون هذه مشكلة وكان لدينا خطة احتياطية” بدلاً من أن نقول “أوه لا، لقد صدمنا هذا الأمر”.
• تعريف “تم” (DoD): تحدثنا عنه في المرحلة 4 - وجود قائمة مرجعية لما تعنيه كلمة “تم” لمهمة أو قصة. قم بطباعته ولصقه على الحائط (أو ما يعادله رقميًا، قم بتثبيته في جهاز تتبع مشروعك). تأكد من أن الجميع يتبعه. يجب أن تتضمن أشياء مثل: مراجعة التعليمات البرمجية، واختبارات مكتوبة واجتيازها، وتحديث الوثائق، ومعالجة المتطلبات ذات الصلة، وما إلى ذلك. وهذا يمنع المخرجات غير المكتملة من المضي قدمًا. خاصة في IoT، حيث قد يتطلب التغيير في firmware تغييرًا في دليل المستخدم أو إعادة معايرة الأجهزة، فإن هذه الخطوات في وزارة الدفاع تذكّر الفريق بأن “تم ذلك” تعني “تم بالفعل”.
• ** العروض التوضيحية الأسبوعية والتواصل المفتوح: ** تشجيع ثقافة ** العرض والتحدث **. في الاجتماعات الأسبوعية، اطلب من كل فريق فرعي أن يعرض شيئًا جديدًا أو مثيرًا للاهتمام. قد يكون الأمر تافهًا (مثل “يتحول مؤشر LED الآن إلى اللون الأخضر عند الاتصال بشبكة Wi-Fi”)، ولكنه يحافظ على الزخم ويساعد في اكتشاف مشكلات التكامل. غالبًا ما يثير العرض التوضيحي شخصًا من فريق آخر ليقول: “مرحبًا، عندما تفعل ذلك، أحتاج إلى تعديل هذا من جانبي”، وهو أمر رائع لاكتشاف الاختلالات مبكرًا. كما أنه يمنح أصحاب المصلحة (رئيسك، مالك المنتج، أو حتى العملاء الودودين) رؤية واضحة للتقدم، مما يبني الثقة.
• استخدام الأدوات الحديثة: قد يبدو هذا واضحًا، ولكن تأكد من أنك تستخدم أفضل الأدوات لأداء المهمة.
• استخدم Git للتحكم في الإصدار لكل شيء (التعليمات البرمجية والوثائق والخطط إن أمكن - تتكامل بعض أدوات التخطيط مع Git أو على الأقل يمكنك إصدار المخرجات).
• إعداد خطوط الأنابيب التكامل المستمر (CI) لتشغيل الاختبارات تلقائيًا. هناك العديد من الخدمات وهي تستحق وقت الإعداد الأولي للوقت الذي ستوفر فيه مشكلات الالتقاط.- التحليل الثابت الآلي: دمج الأدوات (هناك الكثير، بعضها مدمج في IDEs، وبعضها مستقل مثل Coverity، وCppcheck، وما إلى ذلك) لمسح التعليمات البرمجية عند كل التزام. إنهم يلتقطون أشياء قد يفوتها البشر.
• للتضمين، فكر في استخدام أداة تتبع RTOS (تحتوي العديد من أنظمة RTOS على ميزات التتبع) التي تتيح لك تسجيل توقيتات المهام وتفاعلاتها. عندما يحدث شيء غريب على الجهاز، يمكن أن يكون التتبع بمثابة المنقذ لتشخيص مشكلات الترابط أو اختناقات الأداء.
• بالنسبة إلى السحابة، تعامل مع البنية التحتية كتعليمات برمجية باستخدام أدوات مثل Terraform أو Pulumi. بدلاً من النقر يدويًا لإعداد الخوادم أو قواعد البيانات، يمكنك كتابة ملفات التكوين التي تحدد موارد السحابة الخاصة بك. وهذا يجعلها قابلة للتكرار (تدوير بيئة مرحلية مماثلة للإنتاج في دقائق) وقابلة للتتبع (التكوين تحت التحكم في الإصدار، لذلك تتم مراجعة التغييرات في البنية التحتية تمامًا مثل التعليمات البرمجية).
• الأتمتة حيثما أمكنك ذلك: إذا وجدت نفسك تقوم بخطوة يدوية بشكل متكرر (مثل إنشاء تقرير أو نقل ملف ثنائي من هنا إلى هناك)، فانظر ما إذا كان من الممكن تشغيلها تلقائيًا باستخدام برنامج نصي أو وظيفة CI. إنه يقلل من الأخطاء البشرية ويحررك للقيام بعمل أكثر أهمية.
• التوثيق كرمز وCI: لقد ذكرنا هذا بالفعل ولكن من الجدير التأكيد عليه كنصيحة: احتفظ بالمخططات والمستندات بالقرب من الكود. إذا كنت تستخدم موقع wiki، فتأكد من تحديثه كجزء من المهام، أو إذا كنت تستخدم الريبو للتوثيق، فقم بفرض التحديثات عبر طلبات السحب. لدى بعض الفرق أيضًا وظائف CI التي تتحقق مما إذا تم تغيير كلمات رئيسية معينة في التعليمات البرمجية (مثل تنسيق الرسالة) ثم تفشل إذا لم يتم تغيير المستندات وفقًا لذلك. قد يبدو الأمر مبالغًا فيه، ولكن ليس هناك ما هو أكثر مبالغة من شحن الأجهزة بتعليمات خاطئة أو واجهات قديمة لأن أحد الأشخاص نسي تحديث مستند ما.
• الفريق والتواصل: أخيرًا، نصيحة أكثر ليونة: تعزيز ثقافة التواصل المفتوح وحل المشكلات بلا لوم. يمكن أن تصبح مشاريع IoT المعقدة مرهقة، وقد تسوء الأمور. عندما يفشل الاختبار أو يتم العثور على خطأ، فبدلاً من إلقاء اللوم على الشخص الذي كتب ذلك الرمز أو صمم تلك الدائرة، ركز على حلها والتعلم منها. قم بإجراء عمليات فحص ما بعد الوفاة للمشكلات الرئيسية (مثل لماذا هرب هذا الخطأ إلى الإنتاج؟ ما الذي يمكننا تحسينه في عمليتنا لاكتشاف ذلك في المستقبل؟). شجع أعضاء الفريق على إثارة المخاوف في وقت مبكر (إذا اعتقد المطور أن أحد المتطلبات غير واقعي، فيجب أن يشعروا بالأمان للتعبير عن ذلك، وعدم التزام الصمت حتى ينفجر الأمر لاحقًا).

إن اتباع هذه العملية المرحلية والمتكررة وممارسات إدارة المشروع هذه يمنحك نهجًا تطويريًا صارمًا وسريعًا. فهو يحافظ على الأجهزة والجوانب الثقيلة للامتثال على المسار الصحيح (حيث لا يمكنك حقًا تحمل الأخطاء غير المتقنة) مع تمكين ردود الفعل السريعة والقدرة على التكيف التي تحتاجها firmware الحديثة وتطوير السحابة. إنه أفضل ما في العالمين: دقة الطراز V وسرعة Agile.

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

تذكر أن كل أداة IoT الناجحة التي تعجبك (من منظمات الحرارة الذكية إلى أجهزة الاستشعار الصناعية) مرت بهذه المرحلة الصعبة. إذن أنت بصحبة جيدة. كن منظمًا، وحافظ على المرونة، ولا تنس الاستمتاع بالعملية - ففي النهاية، بناء شيء جديد هو أمر رائع. حظًا سعيدًا في تحقيق فكرة IoT الخاصة بك، ومرحبًا بك في المغامرة!🚀