فصل 4: ابزارهای مهندسی سیستم

این فصل به منظور ارائه نمونه های تکمیلی از کاربرد ابزارهای مهندسی سیستم است که ممکن است در طی فرآیند طراحی SE توسط یک تیم دانشجویی مورد نیاز باشد. مطمئناً این همه شامل وسعت و پیچیدگی ابزارهای موجود در صنعت نیست. آنچه در اینجا ارائه می شود برخی از ابزارهای اصلی هستند ، برخی از آنها اساسی و ساده برای کاربرد آسان برای یک پروژه دانشجویی.

زمان خوبی برای تقویت ایده هنر مهندسی سیستم در مقایسه با "ابزارهای" هنرمند است. تمرین ، درک ، نگهداری و خیاطی از هر مجموعه ابزار در همه حرفه ها ضروری است ، اما اگر ابزارها به هدف هنر تبدیل شوند یا هدف نهایی به خودی خود باشد ، استاد خود را شکست خورده است. در زمینه هوایی فنی و بسیار پیچیده هوافضا ، خطر استفاده بیش از حد و اتکا به ابزارهای SE برای تولید یک محصول موفق در نگاه مشتری است. فقط مهندسی صدا و قضاوت خوب از این نظر پیروز خواهد شد ، در حالی که بیش از اتکا به "این روند" فقط به یک برده مهندس سیستم کمک می کند و مانع مهم موفقیت موفقیت را از طریق توجه بیش از حد سخت به پر کردن اسناد ، ایجاد مهلت ها ، اضافه می کند. بودجه ها و ارائه داده های ناشایست. بنابراین ابزارها را با نیتی که در آن خدمت می کنند ، اعمال کنید:

1. کمک در ارتباطات
2. از خطاهای "گنگ" جلوگیری کنید
3. مهمترین مشکلات یا مسائل را برجسته کنید
4. از بی انتها اطمینان حاصل کنید
5. بهترین محصول ممکن را برای وضعیت معین تولید کنید

با ابزارها به این صورت رفتار نکنید:

1. مهمترین چیز در مورد پروژه
2. تعویض مهندسی خوب یا قضاوت صدا
3. فرآیند اطمینان از حذف همه (به ویژه طراحی) از بین رفته است
4. آنچه برای تولید دریافت می کنید (یا درجه بندی می شوید).

تابع

سند به شکل رئوس مطالب

ساختار تجزیه محصول (PBS) ،

مفهوم عملیات

تأیید و تأیید

سند کنترل رابط

بودجه ، قدرت ، هزینه ، بودجه پیوند

تجزیه و تحلیل حالت شکست

اسناد ذخیره و پایه

توابع مدیریت

ساختار شکست کار (WBS) ، نمودار گانت ، SEMP

جدول 1. ابزارهای مهندسی سیستم.*ابزارهای دیگر برای طراحی معماری کاربرد دارد اما در این فصل ارائه نشده است ، مانند تجزیه و تحلیل عملکردی یا تجزیه عملکردی (به عنوان مثال در فصل 2 مراجعه کنید) ، ماتریس تصمیم گیری ، خانه کیفیت علاوه بر شبیه سازی نرم افزار (به عنوان مثال در فصل 8 مراجعه کنید) ،نمونه سازی و مدل سازی.

ساختار تجزیه محصول (PBS)

A product breakdown structure (PBS) is a hierarchical breakdown of the hardware and software products of the project. It is created as part of the SE architectural design function. The following example (Figure 1) comes from (NASA, 2007). These can be created in PowerPoint using the Insert> Diagram>چارت سازمانی. برخی از اختیار ها را می توان برای ترکیب بلوک ها (اغلب برای پروژه های کوچکتر) یا افزودن ویژگی به دیگران استفاده کرد. PBS مناطقی را که باید کار می شود و از تکالیف کار ، بودجه بندی و سایر توسعه ابزار SE پشتیبانی می کند ، ارتباط برقرار می کند. برای پروژه SOFIA (شکل 2) ، دو زیر سیستم اصلی سیستم رصدخانه و سیستم زمینی هستند.

شکل 1. ساختار تجزیه محصول ناسا (PBS) برای یک وسیله نقلیه پرتاب

شکل 2. مثال PBS برای تلسکوپ مادون قرمز SOFIA.

ساختار شکست کار (WBS)

شکل 3 یک ساختار تجزیه کار یا WBS (یک بخش سلسله مراتبی از سخت افزار ، نرم افزار ، خدمات و داده ها) برای سیستم SOFIA مثال نمونه شکل 2 نشان می دهد. WBS درختی از تلاشهای تقسیم شده برای دستیابی به هدف نهایی است ، باید شامل همه کارها باشدکارکرد. کارکردهای کار اضافی در WBS که در PBS یافت نمی شود شامل مدیریت پروژه ، مهندسی سیستم ها و غیره (از (ناسا ، 1995)). WBS همچنین در تهیه تخمین هزینه ، نیازهای نیروی انسانی و غیره می افزاید. این سند مانند همه ابزارهای SE متناسب با کت و شلوار پروژه است. این باید برای کار مفید و کاربردی باشد و نه فقط یک کپی از "آخرین بسته پروژه" که در بررسی بعدی یا توجیهی قرار دارد. یک قانون خوب برای استفاده با همه ابزارهای SE: اگر عملکردی برای پشتیبانی از پروژه ندارد ، نباید از آن استفاده کرد. در مورد پروژه های دانشجویی کوچک ، هدف یادگیری ممکن است درج ابزارهای فرآیند در غیر این صورت سوال برانگیز و ردیابی بسیار مهم باشد. علاوه بر این ، پروژه های دانشجویی که از یک کلاس یا گروهی از دانش آموزان به دیگری منتقل می شوند ، مستندات واضح را از طریق مدیریت پیکربندی یک ضرورت بیشتر می کنند.

شکل 3. پروژه SOFIA با بالاترین سطح WBS ، و جزئیات سیستم رصدخانه WBS.

WBS بسیاری از عناصر مشابه PBS را شامل می شود اما مواردی از قبیل مدیریت ، ایمنی ، قابلیت اطمینان یا سایر فعالیت های نظارتی قابل توجه را اضافه می کند. این ممکن است به عنوان "مردم" مؤلفه های مشتق شده تصور شود در حالی که PBS بیشتر "چیزهایی" است که پروژه را تشکیل می دهد. باز هم ، هدف این است که پیچیدگی و ماهیت پروژه ، تحریک فرایند طراحی و مهندسی و جلوگیری از حذف یا کپی های آشکار ، ارتباط برقرار کنیم.

این WBS بعدی نمونه ای از چگونگی تنظیم WBS سنتی برای یک کار مهندسی سیستم های غیرمعمول یا پیشرفته است. سیستم راه اندازی مجدد الکترودینامیکی Exchange (MXER) یک فضای 100 کیلومتری است که می تواند ماهواره ای را انتخاب کند و آن را در یک مسیر به Geo ، ماه یا فضای بین سیاره پرتاب کند. با فشار دادن روی میدان مغناطیسی زمین دوباره راه اندازی مجدد می شود و می تواند آماده انتقال حرکت به ماهواره بعدی که به لئو پرتاب شده است ، آماده شود. توجه داشته باشید که چگونه مؤلفه ها و نیازهای منحصر به فرد آن در WBS ضبط می شود."کد تبلیغ کننده" یک الگوریتم رایانه ای جداگانه است که پیش بینی می کند که انتهای اتصال در Rendezvous قرار خواهد گرفت. از آنجا که این یک عامل اصلی برای طراحی ، کنترل و عملیات بود ، یک منطقه سطح بالا برای کار بود. این می تواند به عنوان یک مورد ردیف پایین تر در یک منطقه سنتی هواپیمایی یا کنترل فضاپیما درج شود ، اما در این پروژه توسعه فناوری به بهترین وجه در شکستن آن در بالا ارائه می شد. چگونه کسی می داند چه موقع این کار را انجام دهد؟این هنر مهندسی سیستم است! تجربه ، شهود مهندسی و مشاوره با اعضای تیم طراحی ، روشهای معمولی است که این داوری را انجام می دهد. این هرگز نباید بر اساس اسناد آخرین پروژه باشد زیرا "برش و چسباندن" آسان است و به سمت ابزار SE بعدی حرکت می کند.

شکل 4. MXER (Reboost Electrodynamic Exchange Momentum) ساختار شکست کار

WBS لازم نیست نمودار سلسله مراتبی باشد. مثال WBS را در فصل 2 مشاهده کنید که بر اساس نمودار GANTT و یک ساختار طرح کلی WBS با استفاده از MS-Project است.

مطالعات تجاری

یک مطالعه تجاری ابزاری است که برای کمک به انتخاب راه حل یک مشکل یا محدود کردن منطقه توسعه برای یک پروژه خاص استفاده می شود. آنها غالباً در چرخه توسعه محصول مورد استفاده قرار می گیرند و در صورت استفاده صحیح ، می توانند یکی از مهمترین کارهای مهندسی در چرخه زندگی یک محصول باشند. در پروژه های بسیار پیشرفته یا طراحی "سیستم های سیستم" ، مطالعه تجارت اغلب بسیار پیچیده است و جزئیات مهندسی در برخی زمینه ها به فرایند طراحی واقعی نزدیک می شود. این مطالعات همچنین در تعریف و روشن کردن چه عواملی واقعاً تأثیرگذارترین موفقیت در کار هستند. شگفت آور ترین نتایج باید در این مطالعات اولیه (فاز A یا B) تجارت باشد ، اگر اینگونه نباشد ، شگفتی ها در پایان یک پروژه به وجود می آید که زمان و پول مورد نیاز برای ایجاد تغییر بیش از حد است.

اگر یک مسئله چندین راه حل داشته باشد، یک مطالعه تجاری راه حل ها را با دادن مقدار عددی به هر راه حل رتبه بندی می کند. یک روش ساده، تعیین یک مقدار عددی برای هر گزینه است. این اغلب بر اساس فاکتورهای وزن و یک مقیاس نرمال سازی برای معیارهای ارزیابی انجام می شود. معیارهای ارزیابی عوامل مهمی هستند که می خواهیم در مطالعه تجارت لحاظ کنیم. عوامل وزن برای تعیین میزان اهمیت معیارهای ارزیابی نسبت به یکدیگر استفاده می شود. مقیاس نرمال سازی یک مقیاس فاصله ثابت ایجاد می کند که به ما امکان می دهد برای هر یک از معیارهای ارزیابی یک مقدار عددی تعیین کنیم.

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

در برخی از فضاهای تجاری بسیار نزدیک، ممکن است تمایل به تمایز بین گزینه های مختلف و ترازوی توزین ردیفی (به عنوان مثال، مقیاس وزنی 1، 3 و 9) به کار گرفته شود. این به عمد تفاوت های کوچک بین گزینه ها را افزایش می دهد تا یک "برنده" واضح مشخص شود. چنین طرح هایی باید با دقت بسیار مورد استفاده قرار گیرند و تنها زمانی که تمایز گزینه ها واقعا غیرممکن باشد.

مراحل مطالعه تجارت ساده

1-مشکل را تعریف کنید.

2. محدودیت هایی را برای راه حل ها تعریف کنید.

3. 3-5 راه حل پیدا کنید

4. معیارهای ارزیابی را تعریف کنید.

5. فاکتورهای وزن را تعریف کنید

6. مقیاس نرمال سازی را تعریف کنید

7. مطالعه تجاری را پر کنید (به عنوان مثال، قالب صفحه گسترده)

8. راه حل ها را رتبه بندی کنید

مثال مطالعه تجارت - خرید خودرو (از J-M Wersinger و Thor Wilson)

بر اساس مراحل ذکر شده در بالا:

1. من می خواهم پیدا کنم که بهترین گزینه برای یک ماشین جدید چیست.

2. ماشین باید کمتر از 50000 دلار باشد و باید محلی باشد.

3. یک سیویک مشکی با 37000 مایل و قیمت 4000 دلار در شرایط بد. یک BMW قرمز با 57000 مایل و قیمت 17000 دلار در شرایط عالی. یک پاسات سفید با 6000 مایل و قیمت 7000 دلار در شرایط خوب.

4. هزینه، مسافت پیموده شده، وضعیت ماشین، و رنگ ماشین.

5. ضریب وزن 3 را برای هزینه و وضعیت خودرو، 2 برای مسافت پیموده شده و 1 برای رنگ خودرو تعیین کنید.

6. مقیاس های عادی سازی:

مسافت پیموده شده (در 10000)

وضعیت ماشین

رنگ ماشین

جدول 2. مثال مطالعه تجارت

مثال مطالعه تجارت - مقایسه میکروکنترلرها برای CubeSat (AUSSP، 2007)

جدول 3. مثال مطالعه تجارت، میکروکنترلر در مقابل FPGA

این یک مطالعه تجاری است که توسط تیم زیرسیستم C& DH برای ارزیابی نقاط قوت و ضعف نسبی میکروکنترلرهای استاندارد 8 بیتی و FPGAهای Antifuse (قابل برنامه ریزی یکبار مصرف) (Field Programmable Gate Arrays) در برنامه های CubeSat انجام شده است. در حالی که میکروکنترلرها به طور گسترده در برنامه های CubeSat استفاده شده اند، FPGAها یک فناوری نسبتاً جدید هستند که ممکن است راه حلی برای اختلالات تک رویدادی ناشی از تشعشع (SEUs) که در مدار زمین همزمان خورشیدی رایج است، ارائه دهند. معیارهای ارزیابی به گونه ای انتخاب شدند که تجارت یک قطعه سخت افزار خاص از هر دسته را مقایسه نمی کند، بلکه ویژگی های اساسی هر قطعه سخت افزار از هر دسته را مقایسه می کند.

نتیجه: تحمل تشعشع ذاتی هر قطعه سخت افزاری که بر روی CubeSat پیاده سازی شده است یک ویژگی بسیار مهم است. در حالی که به نظر می رسید FPGA های ضد فیوز راه حلی برای SEU ها در ماهواره های کوچک هستند، اما در مطالعه تجارت امتیاز بالاتری نسبت به میکروکنترلرهای سنتی تر نداشتند. هنگامی که عملکرد، هزینه، زمان و دامنه اجرای هر سیستم با هم مقایسه می شوند، به نظر می رسد FPGAها تنها مقوله عملکرد را در نظر می گیرند و میکروکنترلرها بقیه را فرا می گیرند. حتی با تحمل تشعشع در 30٪ از کل امتیاز وزنی (نمونه ای از بایاس کردن تجزیه و تحلیل برای بررسی استحکام نتیجه)، FPGA ها به طور شگفت انگیزی میکروکنترلرها را دنبال می کنند. بدون شک این نوع مطالعه تجاری نتایج بسیار متفاوتی برای ماموریت هایی با منابع بیشتر، زمان بیشتر و مهندسان مجرب تر خواهد داشت. با این حال به نظر می رسد که مسیر صحیح پیاده سازی یک میکروکنترلر استاندارد، همراه با الگوریتم های تشخیص و تصحیح منطقی SEU است.

این یک مقایسه زیرسیستم بود که مفاهیم مهندسی سیستم ها را برای زیرسیستم های دیگر در نظر نمی گرفت، که می توانست کنترل کننده قابل برنامه ریزی استاندارد را بیشتر مستحکم کند. تنها با یک مجموعه از دستورالعمل ها که قابلیت پیاده سازی دارند، کیفیت و قابلیت اطمینان همه زیرسیستم های کنترل شده افزایش می یابد. این زیرسیستم های دیگر باید زودتر تصمیمات فناوری را قفل کنند و توانایی کمتری برای تصحیح مسائل از طریق تغییرات نرم افزاری داشته باشند. از نقطه نظر مهندسی سیستم (یا مدیریت پروژه) تعداد بیشتر SEU، جرم اضافی در حفاظ یا تلاش بیشتر در چیدمان اجزا (استفاده از اثر محافظ مخازن، سازه ها و غیره) همه موارد قابل قبولی برای یک غیر قابل انعطاف هستند. اما تشعشع زیرسیستم C& DH را سخت می کند.

نمونه های سند کنترل رابط

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

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

مهندس سیستم وظیفه نگه داشتن جریان و دقیق ICD را بر عهده دارد. سرب های زیر سیستم اغلب کورکورانه آنچه را که آخرین بار دریافت کرده اند به عنوان مشخصاتی که در حال طراحی و ساخت آنها هستند ، اعمال می کنند. بنابراین مهندس سیستم باید اطمینان حاصل کند که هر تیم به روزرسانی تغییر می یابد و درگیری ها در اوایل مرحله طراحی برطرف می شود. همچنین نیاز به اطمینان از اتاق چیدمان ، جرم ، تماس حرارتی ، استحکام فیزیکی و پارامترهای الکتریکی/داده برای همه زیر سیستم ها و همچنین اهداف ماموریت رضایت بخش است.

نام سیگنال آنالوگ (بین ماژول)

چگونه ارتباط برقرار می کند