Flow پنجاه میلیون دلار گرفت؛ AI از کد به مهندسی سخت‌افزار می‌رود

Flow Engineering، شرکت مستقر در سان‌فرانسیسکو، بنا بر گزارش تک‌کرانچ، در ۳۰ سپتامبر ۲۰۲۶ دور سری B به مبلغ ۵۰ میلیون دلار و با ارزش‌گذاری ۷۵۰ میلیون دلار را اعلام کرد؛ آنتونیو گراسیاس از Valor Equity Partners و گوین بیکر از Atreides Management رهبری مشترک دور را بر عهده داشتند، Sequoia Capital مشارکت کرد و رولوف بوتا به هیئت‌مدیره پیوست. این سرمایه‌گذاری پشت نرم‌افزاری است که تغییر در طرح‌های مهندسی را به الزام‌های محصول، شبیه‌سازی و نتایج آزمون وصل می‌کند.

در شرح Superintelligence News از محصول، Rivian، Anduril، Joby Aviation و Stoke Space در میان مشتریان نام‌برده‌اند و کار عامل‌های Flow هم‌تراز نگه‌داشتن فایل‌های CAD با الزام‌ها، خروجی شبیه‌سازی و داده‌های آزمون توصیف شده است. این همان بخشی از کار مهندسی است که با هر اصلاح طرح باید دوباره بررسی شود.

سرمایهٔ تازه صرف کدام بخش محصول می‌شود

بر پایهٔ اطلاعیهٔ Flow، شمار کاربران سامانه در Rivian طی هفت ماه از ۴۰ به ۱۵۰۰ نفر رسیده و اسکات مکنزی، مدیر توسعهٔ محصول این خودروساز، گفته است: «We evaluated 30 tools and nothing came close to Flow.» این اعداد و ارزیابی به استفاده از محصول و نظر یک مشتری مربوط‌اند؛ میزان دقت عامل‌ها در یافتن تعارض یا کاهش زمان توسعه را به‌تنهایی اندازه نمی‌گیرند.

برنامهٔ Flow برای سرمایهٔ جدید، گسترش قابلیت‌های بازبینی، شاخه‌بندی، ارزیابی و کنترل عامل‌های مهندسی است. شرکت همچنین توسعهٔ تیم‌های هوش مصنوعی و مهندسی سیستم، افزایش ظرفیت فروش و پیگیری مجوز FedRAMP و گواهی‌های دیگر را در برنامه دارد. پیگیری مجوز به معنی دریافت آن نیست؛ برای مشتریانی که روی داده‌های فنی حساس کار می‌کنند، وضعیت مجوز و سطح دسترسی عامل‌ها بخشی از تصمیم استقرار خواهد بود.

حضور Sequoia Capital، سرمایه‌گذار دور پیشین، و ورود بوتا به هیئت‌مدیره دامنهٔ پشتوانهٔ مالی و مدیریتی Flow را نشان می‌دهد، اما ارزش‌گذاری این دور قیمت توافق‌شده در معاملهٔ سرمایه‌گذاری است. از آن نمی‌توان درآمد شرکت، سودآوری یا کارایی فنی عامل‌ها را نتیجه گرفت. نشانهٔ عملی‌تر برای مهندسان این است که پول تازه به ابزارهایی مانند بازبینی و ارزیابی اختصاص می‌یابد؛ یعنی همان نقاطی که رفتار عامل در یک پروژهٔ واقعی باید قابل‌ردگیری و قابل‌مهار باشد.

عامل‌ها میان CAD، الزام‌ها و آزمون چه می‌کنند

محصول Flow یک مرجع زنده برای رابطهٔ میان الزام‌ها، CAD، کد، شبیه‌سازی و آزمون می‌سازد. عامل‌ها تغییرات هر بخش را دنبال می‌کنند، اثر احتمالی آن‌ها را در بخش‌های وابسته پیدا می‌کنند و مواردی را که تطابق با الزام یا پوشش آزمون نیازمند بازبینی است، آشکار می‌کنند. در این مدل، ارزش اصلی تولید یک طرح به‌تنهایی نیست؛ حفظ پیوند میان نسخهٔ طرح، شرط فنی و شاهدی است که قرار است آن شرط را تأیید کند.

در پروژهٔ سخت‌افزاری، یک اصلاح هندسه ممکن است روی قطعهٔ مجاور، نرم‌افزار کنترل یا نتیجهٔ شبیه‌سازی اثر بگذارد. اگر فایل طراحی تازه شود اما نتیجهٔ آزمون همچنان به نسخهٔ پیشین مربوط باشد، نام هر دو در پروندهٔ پروژه وجود دارد ولی کنار هم پاسخ معتبری نمی‌دهند. عامل می‌تواند این فاصله را زودتر در زنجیرهٔ تغییرات پیدا کند؛ مهندس باید تعیین کند کدام رابطه واقعاً فنی و کدام هشدار حاصل دادهٔ ناقص یا پیوند نادرست است.

این شیوه برای تیم‌هایی معنا دارد که در چند ابزار جداگانه کار می‌کنند. CAD محل تعریف شکل و اجزاست، الزام‌ها رفتار مطلوب را بیان می‌کنند و آزمون یا شبیه‌سازی شواهدی برای سنجیدن همان رفتار فراهم می‌آورد. اگر هر بخش با نسخه‌بندی و زبان متفاوت پیش برود، پرسش سادهٔ «این نتیجه کدام طرح را تأیید می‌کند؟» می‌تواند به جست‌وجویی طولانی میان پرونده‌ها تبدیل شود. Flow می‌کوشد این رابطه‌ها را در طول کار زنده نگه دارد، نه فقط هنگام تهیهٔ گزارش نهایی.

از تغییر یک طرح تا تشخیص تعارض

یک مثال فرضی مسیر کار را روشن می‌کند: مهندسی شکل قطعه‌ای را در CAD تغییر می‌دهد و همان قطعه در چند زیرسامانهٔ یک خودرو به کار می‌رود. عامل ابتدا رابطهٔ نسخهٔ جدید با الزام‌های ثبت‌شده را دنبال می‌کند، سپس شبیه‌سازی‌های وابسته و آزمون‌هایی را که بر پایهٔ هندسهٔ قبلی انجام شده‌اند مشخص می‌کند. حاصل مفید این مرحله، فهرست قابل‌پیگیری پیامدهای تغییر و شواهدی است که باید تازه شوند؛ خودِ فهرست حکم ایمنی یا تأیید نهایی محصول نیست.

اگر یکی از الزام‌ها فاصلهٔ مجاز قطعه با جزء دیگری را تعیین کرده باشد، تغییر هندسه ممکن است تعارضی واقعی ایجاد کند. اگر فاصله همچنان مجاز باشد ولی آزمون مربوط به نسخهٔ جدید انجام نشده باشد، مسئله از جنس کمبود شاهد است. این تفاوت بر کار بعدی اثر می‌گذارد: در حالت نخست ممکن است طرح یا برداشت از الزام اصلاح شود؛ در حالت دوم شاید اجرای دوبارهٔ شبیه‌سازی یا آزمون لازم باشد. عامل می‌تواند مورد، دادهٔ مرتبط و مسیر پیدایش هشدار را به بازبین برساند، اما تشخیص فنی و پذیرش هر استثنا با مسئولان مهندسی می‌ماند.

وعدهٔ سرعت به کدام تأییدها وابسته است

هدف Flow کوتاه‌کردن چرخهٔ بازنگری سخت‌افزار است، ولی سرعت یافتن اثر یک تغییر با زمان تأیید محصول یکسان نیست. نتیجهٔ شبیه‌سازی به فرض‌های مدل وابسته است و نتیجهٔ آزمون به شرایط اجرا و نسخهٔ نمونه. حتی وقتی عامل زنجیرهٔ وابستگی را درست پیدا کند، بازبین باید ببیند دادهٔ ورودی کامل بوده، الزام درست تفسیر شده و شاهد تأیید به همان پیکربندی مورد بحث تعلق دارد. بازبینی و ارزیابی عامل‌ها در همین فاصله میان هشدار خودکار و تصمیم مهندسی اهمیت پیدا می‌کند.

نام مشتریان از خودروسازی تا هوافضا نشان می‌دهد Flow مسئلهٔ هماهنگی داده‌ها را در چند نوع برنامهٔ سخت‌افزاری دنبال می‌کند، اما عمق استفاده و نتیجهٔ فنی هر استقرار یکسان گزارش نشده است. گام بعدی شرکت، گسترش ابزارهای بازبینی و کنترل عامل‌هاست؛ در کاربرد مهندسی، کار این ابزارها باید به تیم اجازه دهد مسیر هر هشدار و شواهد آزمون مربوط به آن را پیش از پذیرش تغییر بررسی کند.

بیشتر بخوانید:

• Trebellar هجده میلیون دلار گرفت؛ اجاره‌نامه‌ها خوراک عامل‌های AI شدند
• Paymob سی‌وپنج میلیون دلار گرفت؛ درآمد خلیج فارس هفت‌برابر شد
• صندوق ۱۵۶ میلیون‌دلاری ZIP؛ سرمایهٔ AI به زیرساخت فیزیکی می‌رود