«سمت چپ V»

بخش قبلی: مرحله 2

مرحله 3 جایی است که طراحی فیزیکی می‌شود: طراحی الکترونیک و مکانیک، که معمولاً دست‌در‌دست هم پیش می‌روند. اگر V-model در مهندسی به گوشتان خورده (یک مدل کلاسیک فرایند توسعه)، سمت چپ «V» همه‌اش طراحی و پیاده‌سازی است—و دقیقاً همین‌جایییم. به عبارت دیگر، روی طراحی سخت‌افزاری تمرکز می‌کنیم که بعداً در سمت راست V راستی‌آزمایی و اعتبارسنجی خواهد شد. (اگر با V-model آشنا نیستید نگران نباشید؛ ایده کلیدی این است که طراحی سخت‌افزار تمایل به فرایندی ترتیبی دارد که باید با دقت به آن نزدیک شد. وقتی یک برد مدار را چاپ یا یک قاب پلاستیکی را قالب بزنید، ایجاد تغییر پیچیده می‌شود—بخوانید: گران.)

مرحله 3 را می‌توان به چند زیرگام تقسیم کرد. نکته مهم اینکه، این مرحله همچنین جایی است که توسعه سخت‌افزار و نرم‌افزار شروع به کار موازی می‌کنند (درباره سمت نرم‌افزار در مرحله بعد بیشتر می‌گوییم). در مسیر سخت‌افزار، اتفاق‌ها معمولاً این‌طور می‌افتد:

ترسیم شماتیک: نقشه الکترونیکی

هر محصول الکترونیکی به‌عنوان یک نقشه شروع می‌شود—نه از نوع هنری، بلکه یک شماتیک. ترسیم شماتیک جایی است که طراحی مدار الکتریکی با جزئیات و با ابزارهای CAD تخصصی (مثل Altium، Eagle یا KiCad) ترسیم می‌شود. شماتیک را نقشه مدارتان بدانید: هر جزء (میکروکنترلر، سنسورها، خازن‌ها، کانکتورها و بیشتر) و نحوه اتصال الکتریکی‌شان توسط نت‌ها (سیم‌ها) را نشان می‌دهد. مثل نقشه‌کشی یک شهر از الکترونیک است که هر جزء یک ساختمان است و نت‌ها جاده‌های رابط بینشان.

این قدم حیاتی است چون رفع اشتباه‌ها روی یک دیاگرام بسیار آسان‌تر (و ارزان‌تر) از روی یک برد فیزیکی است. وقتی شماتیک پیش‌نویس شد، یک بازبینی کامل واجب است. معمولاً مهندس شماتیک را به PDF خروجی می‌دهد و برای بازبینی همتا می‌چرخاند. چشم‌های تازه ممکن است چیزی را بگیرند که از دست شما در رفته—مثلاً «اوه، پین تغذیه سنسور دما وصل نیست!» یا «مقدار آن مقاومت برای محدودکننده جریان LED درست به نظر نمی‌رسد.» گرفتن این مسائل حالا از سردردهای زیاد بعد جلوگیری می‌کند.

در این مرحله بعضی تیم‌ها یک FMEA (تحلیل حالت‌های خرابی و اثرات) هم روی بخش‌های حیاتی طراحی اجرا می‌کنند، مثل منبع تغذیه یا مدارهای ایمنی. FMEA در اصل روشی ساخت‌یافته برای پرسیدن «این مدار به چه شکل‌هایی می‌تواند خراب شود، و اگر بشود چه اتفاقی می‌افتد؟» است. مثلاً، اگر سنسور دما اتصال کوتاه شود (یعنی دو پایه‌اش به‌تصادف از داخل به هم وصل شوند) چه؟ آیا فقط سنسور یک مقدار افراطی می‌خواند، یا می‌تواند با کشیدن جریان زیاد کل برد را خراب کند؟ با پرسیدن زودهنگام این پرسش‌های ناراحت‌کننده «اگر-چه»، می‌توانید محافظت‌ها را اضافه کنید یا تصمیم بگیرید ریسک قابل‌قبول است. این نوع تفکر آینده‌نگر، دستگاه را در بلندمدت قابل اعتمادتر می‌کند.

در همین حین—و این‌جا همان‌جایی است که کار موازی وارد می‌شود—تیم نرم‌افزار/firmware لازم نیست بیکار منتظر تمام‌شدن سخت‌افزار بماند. بر اساس شماتیک، مهندسان firmware می‌توانند شروع به ساختن یک HAL (Hardware Abstraction Layer) یا دست‌کم اسکلتی از آن کنند. در اصل، رابط‌های نرم‌افزاری پریفرال‌های میکروکنترلر را راه می‌اندازند (تایمرها، رابط‌های ارتباطی مثل I2C یا SPI برای آن سنسورها و غیره). حتی ممکن است تست‌های واحد یا کد شبیه‌سازی برای این درایورها روی PC بنویسند. توسعه‌دهنده‌ای را تصور کنید که کدی می‌نویسد که خوانش‌های سنسور را جعل می‌کند فقط برای تست منطق—این‌طوری تیم firmware از همین حالا دارد بنیان را می‌سازد. پس تا وقتی برد مدار واقعی برسد، خیلی از ساختار کد آماده است و منتظر امتحان روی سخت‌افزار واقعی است. این تلاش موازی یعنی نرم‌افزاری‌ها سرشان گرم است؛ دارند زمینه‌ای می‌چینند که راه‌اندازی سخت‌افزار را بعداً آسان‌تر می‌کند.

چیدمان PCB: از شماتیک تا برد فیزیکی

وقتی طراحی شماتیک نهایی و بازبینی شد، وقت تبدیل آن نقشه الکترونیکی به یک برد مدار واقعی است. این فاز چیدمان PCB است. با مجموعه دیگری از ابزارهای CAD (اغلب همان مجموعه‌ای که برای شماتیک استفاده شد، مثل Altium یا KiCad که می‌تواند به حالت چیدمان سوئیچ کند)، مهندس هر footprint جزء را روی یک برد مجازی می‌نشاند و شروع به مسیریابی ردپاهای مسی می‌کند که همه‌چیز را وصل می‌کند. اگر شماتیک نقشه است، چیدمان PCB قدمی است که در آن دقیقاً تصمیم می‌گیرید آن شهر از اجزا از نظر فیزیکی چه شکلی خواهد بود—مثل تصمیم‌گرفتن که هر ساختمان کجا می‌نشیند و جاده‌ها (سیم‌ها) چگونه روی منظره واقعی برد می‌گذرند.

نتیجه چیدمان PCB مجموعه‌ای از فایل‌هاست (معروف به فایل‌های Gerber) که سازندگان برای ساخت برد استفاده می‌کنند. یک خروجی مفید دیگر یک مدل سه‌بعدی (اغلب یک فایل STEP) از برد است. این مدل سه‌بعدی مخصوصاً در سمت طراحی مکانیکی مفید است—می‌توانید آن را به طراحی محفظه‌تان وارد کنید تا بررسی کنید برد و همه اجزایش بدون هیچ برخوردی درون بدنه محصول جا می‌شوند (هیچ‌کس نمی‌خواهد یک کانکتور USB از جایی بیرون بزند که قاب سوراخی ندارد!).

حین چیدمان PCB، حیاتی است که رهنمودهای طراحی برای تولید (DFM) و طراحی برای تست (DFT) را در نظر داشته باشید. به زبان ساده، DFM یعنی طراحی برد طوری که بتوان آن را مطمئن و مقرون‌به‌صرفه تولید کرد، و DFT یعنی طراحی‌اش طوری که بعداً به‌آسانی تست شود.

مثلاً:

• DFM: از نشاندن اجزا زیادی نزدیک به لبه برد یا آن‌قدر فشرده که دستگاه‌های مونتاژ برای لحیم‌کردنشان به زحمت بیفتند دوری کنید. مطمئن شوید چیدمان بدون مشکل قابل تولید است.
• DFT: پدهای تست یا یک کانکتور مخصوص اضافه کنید تا بتوانید تجهیزات تست یا پروگرامرها را در تولید به برد وصل کنید. این‌طوری هر واحدی که از خط بیرون می‌آید به‌آسانی قابل بررسی است (یک سوکت راحت برای برنامه‌ریزی firmware یا اندازه‌گیری سیگنال‌ها روی هر دستگاه را تصور کنید).

گنجاندن این تدابیر حالا بسیار آسان‌تر از فهمیدن بعداً است که هزار واحد تمام‌شده دارید و راه آسانی برای بررسی کارکرد کاملشان نیست!

بسیاری از تیم‌ها حین چیدمان از یک چک‌لیست استفاده می‌کنند تا مطمئن شوند هیچ‌چیز فراموش نشده—چیزهایی مثل افزودن fiducialها (علامت‌های کوچکی که به دستگاه‌های مونتاژ خودکار کمک می‌کند بفهمند برد را چگونه تراز کنند)، حفظ فاصله‌های درست بین بخش‌های ولتاژبالا، برچسب‌گذاری کانکتورهای مهم و مانند این‌ها.

در حالی که تیم سخت‌افزار مشغول مسیریابی ردپاها و جزئیات برد است، تلاش نرم‌افزاری موازی ادامه دارد. تیم firmware، با دانستن مدل‌های دقیق سنسور و اجزا از روی شماتیک، می‌تواند شروع به نوشتن کد درایور واقعی (یا دست‌کم جای‌نگهدارها) بر اساس دیتاشیت‌های آن اجزا کند. ممکن است از شبیه‌سازهای سنسور استفاده کنند یا کد ساختگی بنویسند که آنچه سنسور می‌خواست انجام دهد را تقلید کند. تیم cloud/backend هم، اگر محصول IoTتان یکی دارد، می‌تواند جلو بیفتد: مثلاً راه‌اندازی یک دیتابیس ابری پایه و endpointهای API برای دریافت داده از دستگاه. در اصل، همه دارند قطعه پازل خودشان را آماده می‌کنند تا وقتی اولین بردهای فیزیکی برسد، برای بقیه تیم شروع سرد نباشد. تا وقتی طراحی PCB برای ساخت ارسال می‌شود، firmware شما ممکن است از قبل یک «hello world» برای برد آماده داشته باشد و cloudتان یک سرور تست کوچک که منتظر لاگ‌کردن اولین نقطه داده دستگاه است. این توسعه هم‌زمان واقعاً حلقه تکرار را بعداً کوتاه می‌کند.

ساخت نمونه اولیه: جان‌دادن به سخت‌افزار

با چیدمان PCB تمام‌شده و بررسی‌شده، حالا وقت رفتن از فایل‌های دیجیتال به اشیای فیزیکی است. اولین قدم ساخت بردهاست. معمولاً آن فایل‌های Gerber را به یک کارخانه PCB می‌فرستید (سازندگان سریع PCB زیادی هستند که می‌توانند در چند روز برد تولید کنند). به‌موازات، می‌خواهید مطمئن شوید همه اجزایی که روی برد می‌روند (میکروکنترلر، سنسورها، چیپ‌ها و غیره) در دسترس‌اند. نکته حرفه‌ای: قطعات حیاتی یا طولانی‌تحویل را به محض اطمینان از شماتیک و انتخاب اجزا سفارش دهید! در دوره‌های کمبود جهانی چیپ، بسیاری از تیم‌ها این را به سختی آموختند—نمی‌خواهید 12 هفته برای یک سنسور یا چیپ رادیویی خاص منتظر بمانید در حالی که بردهایتان خالی نشسته‌اند.

وقتی PCBهای لخت و همه قطعات را دارید، چند واحد نمونه اولیه مونتاژ می‌کنید. این می‌تواند درون‌سازمانی انجام شود اگر آزمایشگاهی خوش‌تجهیز و دستی ثابت برای لحیم‌کاری دارید، یا ممکن است از یک سرویس مونتاژ برای لحیم‌کردن همه آن اجزای ریز استفاده کنید. نتیجه مجموعه‌ای (اغلب مشتی کم، مثل 1 تا 5 برد) از دستگاه‌های نمونه اولیه است.

حالا یکی از هیجان‌انگیزترین (و دلهره‌آورترین) لحظه‌های توسعه سخت‌افزار می‌رسد: bring-up، اصطلاح ساده برای اولین باری که برد را روشن می‌کنید و می‌بینید کار می‌کند یا نه. رایج است این کار با احتیاط انجام شود—مثلاً با یک منبع تغذیه رومیزی با محدودیت جریان، تا اگر جایی اتصال کوتاهی هست چیزها نسوزند. همه در آزمایشگاه ممکن است نفسشان را حبس کنند وقتی کلید را می‌زنید. آیا برد بدون رهادن دود جادویی اجزای سوخته روشن می‌شود؟ (امیدوارم بله!)

بعد از روشن‌شدن، پایه‌ها را روشمند بررسی می‌کنید. آیا همه ریل‌های تغذیه ولتاژهای مورد انتظار را دارند؟ (با مولتی‌متر یا اسیلوسکوپ بررسی کنید.) آیا میکروکنترلر (MCU) بیدار می‌شود و کد اجرا می‌کند؟ یک تست اول کلاسیک اغلب بررسی این است که یک firmware ساده که یک LED چشمک می‌زند یا یک پیام «Hello, world» از طریق پورت سریال می‌فرستد در حال اجراست یا نه. اگر آن LED چشمک زد یا آن پیام را روی کامپیوترتان گرفتید، یک نقطه عطف واقعی است—یعنی قلب بردتان زنده است و می‌تپد.

بعد، ارتباط با پریفرال‌های کلیدی را تست می‌کنید: آیا MCU می‌تواند طبق برنامه از طریق I2C یا SPI با سنسور حرف بزند؟ آیا سنسورها داده معقول برمی‌گردانند؟ در همین مرحله است که ممکن است مسائل را کشف کنید. شاید یک سنسور به‌خاطر یک اشتباه سیم‌کشی یا یک باگ ظریف firmware خوانش نمی‌دهد. Bring-up یک بازی کارآگاهی است که مهندسان سخت‌افزار و firmware با هم برای عیب‌یابی مشکلات همکاری می‌کنند. مثلاً، اگر خوانش دما همیشه صفر است، مهندس firmware ممکن است کد را دیباگ کند در حالی که مهندس سخت‌افزار اتصالات را با مولتی‌متر بررسی می‌کند—با هم می‌فهمند مشکل مقداردهی اولیه نرم‌افزار است یا شاید خطوط SDA و SCL سنسور روی PCB جابه‌جا شده‌اند.

حین bring-up نمونه اولیه، مراقب مسائل تغذیه یا حرارتی هم هستید. آیا چیزی بیش از حدی که باید داغ می‌شود؟ (نکته حرفه‌ای: لمس محتاطانه چیپ‌ها برای حس‌کردن گرما یا استفاده از دوربین مادون قرمز می‌تواند نقاط داغ را بگیرد.) آیا برد بیش از انتظار جریان می‌کشد (که می‌تواند نشانه سیم‌کشی اشتباه یا قطعه معیوب باشد)؟ این تست‌ها تضمین می‌کنند نمونه اولیه‌تان نه‌فقط کار می‌کند، بلکه امن است و در پارامترهای مورد انتظار عمل می‌کند.

اگر دستگاهتان قرار است بی‌سیم ارتباط برقرار کند یا استانداردهای قانونی خاصی را بگیرد (مثل انتشارات FCC برای گجت‌های بی‌سیم در آمریکا)، این مرحله نمونه اولیه زمان خوبی برای کمی تست پیش‌انطباق است. این می‌تواند یعنی بردن دستگاه به آزمایشگاهی برای یک اسکن مقدماتی انتشارات فرکانس رادیویی تا مشکلات بزرگ زود گرفته شوند. نمی‌خواهید در تست گواهی‌نامه نهایی بفهمید بردتان دارد در یک فرکانس غیرمجاز مثل یک فرستنده رادیویی تصادفی رفتار می‌کند!

در حالی که تیم سخت‌افزار مشغول bring-up است، تیم firmware حالا به‌کامل دارد کدش را روی دستگاه واقعی تست می‌کند. همه آن درایورها و اجزای HAL که قبلاً شروع کرده بودند می‌توانند روی برد واقعی بارگذاری شوند. این‌جا همان‌جایی است که firmware ممکن است به کمی تنظیم نیاز داشته باشد—شاید فرضیه‌های زمان‌بندی کمی اشتباه بوده، یا یک interrupt حالا که روی سیلیکون واقعی است به تنظیم نیاز دارد. اگر از یک RTOS (سیستم‌عامل بلادرنگ) روی میکروکنترلر استفاده می‌کنید، حالا وقت شروع تنظیم اولویت‌ها یا زمان‌بندی تسک‌هاست، چون روی سخت‌افزار واقعی می‌توانید عملکرد واقعی را مشاهده کنید. تیم cloud هم ممکن است اولین داده واقعی را ببیند که از سیستم می‌آید! مثلاً نمونه اولیه ممکن است واقعاً یک خوانش دما به یک سرور تست بفرستد و تأیید کند که کل جریان سرتاسری (دستگاه → cloud → دیتابیس) دست‌کم در مقیاس کوچک کار می‌کند.

مرحله 3 اغلب چند تکرار دارد. گرفتن همه‌چیز کامل در اولین تلاش نادر است—و کاملاً طبیعی است. ممکن است اشتباهی روی برد پیدا کنید (مثل ردپایی اشتباه وصل‌شده یا خطای footprint یک جزء) که یک اصلاح جراحی کوچک روی نمونه‌های اولیه بخواهد (سلام به سیم‌های bodge و اصلاحات پچ‌ورک!)، یا آن‌قدر مهم باشد که چاپ یک PCB بازبینی‌شده برای دور بعدی نمونه اولیه را بخواهد. هر تکرار فرصتی برای بهترکردن است: شاید یک کانکتور که دسترسی‌اش سخت بود را جابه‌جا کنید، یا مدار را برای کاهش نویز روی خوانش یک سنسور تنظیم کنید و غیره. از نیاز به تکرارها دلسرد نشوید؛ در توسعه سخت‌افزار مورد انتظار است.

در سراسر این مرحله، همکاری نزدیک بین تیم‌های سخت‌افزار و نرم‌افزار حیاتی است. وقتی مسئله‌ای پیش می‌آید، هر دو طرف باید کلاه کارآگاهی بگذارند و با هم کار کنند. سنسور به‌خاطر اشتباه‌بودن firmware خوانش نمی‌دهد، یا یک پل لحیم چیزی را روی PCB اتصال کوتاه کرده؟ با ارتباط یافته‌ها و فرضیه‌ها، تیم می‌تواند سریع‌تر به مشکل برسد. این عیب‌یابی مشترک یکی از آموزنده‌ترین بخش‌های فرایند است—و اغلب درک تیم از محصول به‌عنوان یک کل را هم تقویت می‌کند.

همچنین، یک چشم به آینده داشته باشید: اگر قصد دارید سرانجام این محصول را در مقیاس تولید کنید، از این فاز نمونه اولیه برای فکرکردن به تولید و تست در بلندمدت استفاده کنید. DFM و DFT یادتان هست؟ حالا وقت اعتبارسنجی آن تصمیم‌هاست. مثلاً، اگر یک هدر برنامه‌ریزی گذاشته‌اید، استفاده از آن را در یک تست تولید شبیه‌سازی‌شده امتحان کنید: آیا به‌آسانی می‌توانید به برد وصل شوید و آن را برنامه‌ریزی کنید؟ اگر پدهای تست اضافه کرده‌اید، آیا برای یک تستر bed-of-nails در دسترس‌اند؟ تنظیم طراحی‌تان برای قابلیت تست حالا بسیار آسان‌تر از وقتی است که یک خط تولید در حال کار دارید.

در پایان مرحله 3، باید یک یا چند دستگاه نمونه اولیه کارا و مجموعه‌ای محکم از درس‌های آموخته‌شده داشته باشید. داده اولیه عملکرد خواهید داشت (مثل اینکه دستگاهتان واقعاً چقدر توان می‌کشد؟ آیا سنسور در شرایط دنیای واقعی دقیق عمل می‌کند؟). احتمالاً فهرستی از اصلاحات یا بهبودها برای نسخه بعدی هم خواهید داشت. از همه مهم‌تر، بنیان فیزیکی محصول IoTتان را ساخته‌اید—چیزی که می‌توانید در دست بگیرید و واقعاً کار می‌کند.

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