1.目的

邏輯架構(gòu)模型開發(fā)的目的是定義、選擇、和集成系統(tǒng)的邏輯架構(gòu)模型提供了一個框架,來驗證一個對未來的系統(tǒng)將滿足所有操作場景的系統(tǒng)需求,在權(quán)衡系統(tǒng)需求可以探索開發(fā)這樣的系統(tǒng)。

流程的通用輸入包括系統(tǒng)需求、架構(gòu)師識別并用于回答需求的通用架構(gòu)模式、系統(tǒng)分析過程的結(jié)果，以及來自系統(tǒng)驗證和確認(rèn)過程的反饋。根據(jù)所選擇的生命周期模型，這些輸入和輸出以及它們之間的關(guān)系將在整個過程中演進(jìn)和變更(請參閱應(yīng)用生命周期過程)。

流程的一般輸出要么是單個邏輯架構(gòu)模型，要么是一組候選邏輯架構(gòu)模型，以及所選的獨立邏輯架構(gòu)模型及其選擇的基本原理。它們至少包括視圖和模型。這些包括功能、行為和時間視圖，邏輯架構(gòu)模型要素和系統(tǒng)需求之間的可跟蹤矩陣。

2.過程的活動

在此過程中執(zhí)行的主要活動和任務(wù)包括:

識別和分析功能和行為要素:

通過分析功能、接口和操作需求，從系統(tǒng)需求中識別功能、輸入-輸出流、操作模式、模式轉(zhuǎn)換和操作場景。

為每個功能和輸出定義必要的輸入和控制(能量、材料和數(shù)據(jù)流)，從而推論出使用、轉(zhuǎn)換、移動和生成輸入-輸出流所需的功能。

將系統(tǒng)需求分配到功能和行為要素:

通過對性能、有效性和約束需求的分配，正式地描述功能表達(dá)式及其屬性。特別是，研究時間方面的需求，以分配持續(xù)時間，響應(yīng)時間，和頻率的功能。

通過接口、有效性、操作性、時間和約束需求的分配，正式地描述輸入、輸出和控制流表達(dá)式及其屬性。

在系統(tǒng)需求和這些功能和行為要素之間建立可追溯性。

為每個候選項定義候選邏輯架構(gòu)模型:

根據(jù)系統(tǒng)需求(如果有的話)分析操作模式，并/或使用先前定義的要素來建模操作模式的序列和模式的轉(zhuǎn)換。最終將模式分解為子模式，然后為每個操作模式建立一個或多個功能識別和/或使用相關(guān)的通用行為模式的場景。

集成這些功能場景，以獲得系統(tǒng)的行為架構(gòu)模型(動態(tài)行為的完整描述)。

根據(jù)需要分解前面定義的邏輯要素，以查看實現(xiàn)。

為之前定義的邏輯要素分配和合并時間約束，如時間周期、持續(xù)時間、頻率、響應(yīng)時間、超時、停止條件等。

為與決策級別相對應(yīng)的功能定義多個級別的執(zhí)行頻率，以便監(jiān)控系統(tǒng)操作，在這個時間基礎(chǔ)上對處理進(jìn)行優(yōu)先級排序，并在這些執(zhí)行頻率級別之間共享功能，以獲得一個當(dāng)前架構(gòu)模型。

執(zhí)行功能失效模式和效果分析，并根據(jù)需要更新邏輯架構(gòu)要素。

使用模擬器執(zhí)行模型(如果可能的話)，并調(diào)整這些模型以獲得預(yù)期的特性。

集成選擇的獨立邏輯架構(gòu)模型:

通過根據(jù)評估標(biāo)準(zhǔn)(與系統(tǒng)需求相關(guān))評估候選邏輯架構(gòu)模型并對它們進(jìn)行比較，選擇邏輯架構(gòu)，使用系統(tǒng)分析過程來執(zhí)行評估和選擇的決策管理過程(參見系統(tǒng)分析和決策管理主題)。這種選定的邏輯架構(gòu)模型稱為獨立邏輯架構(gòu)模型，因為它盡可能地獨立于實現(xiàn)決策。

識別和定義為設(shè)計的必要性而創(chuàng)建的與派生的系統(tǒng)需求相對應(yīng)的派生的邏輯架構(gòu)模型要素。將這些需求分配給適當(dāng)?shù)南到y(tǒng)(當(dāng)前研究的系統(tǒng)或外部系統(tǒng))。

驗證并驗證所選擇的邏輯架構(gòu)模型(盡可能使用可執(zhí)行的模型)，根據(jù)需要進(jìn)行修正，并建立系統(tǒng)需求和邏輯架構(gòu)模型要素之間的可追溯性。

反饋邏輯架構(gòu)模型開發(fā)和系統(tǒng)需求。此活動在物理架構(gòu)模型開發(fā)過程之后執(zhí)行:

如果可能的話，將分配的邏輯架構(gòu)建模到系統(tǒng)和系統(tǒng)要素，并根據(jù)需要添加任何功能、行為和時間要素來同步功能和處理。

定義或合并由所選邏輯和物理架構(gòu)模型產(chǎn)生的派生邏輯和物理要素。定義相應(yīng)的派生需求，并將它們分配到適當(dāng)?shù)倪壿嫼臀锢砑軜?gòu)要素。將這些派生的需求合并到受影響系統(tǒng)的需求基線中。

3.工件、方法和建模技術(shù)

邏輯架構(gòu)描述使用分組在下列模型類型下的建模技術(shù)。已經(jīng)開發(fā)了幾種方法來支持這些類型的模型(有些是可執(zhí)行模型):

功能模型——包括結(jié)構(gòu)化分析設(shè)計技術(shù)(SADT/IDEF0)、系統(tǒng)分析與實時(SA-RT)、增強(qiáng)功能流框圖(eFFBD)和功能分析系統(tǒng)技術(shù)(FAST)等模型。

語義模型——包括實體關(guān)系圖、類圖和數(shù)據(jù)流圖等模型。

動態(tài)模型——包括狀態(tài)轉(zhuǎn)換圖、狀態(tài)圖、eFFBDs、狀態(tài)機(jī)等模型

圖(SysML)、活動圖(SysML) (OMG 2010)和petri網(wǎng)。

根據(jù)領(lǐng)域的類型(如防御、企業(yè))，架構(gòu)框架提供了可以幫助表示架構(gòu)的其他方面/視圖的描述——參見企業(yè)系統(tǒng)工程關(guān)鍵概念中的“企業(yè)架構(gòu)框架和方法論”一節(jié)。參見使用與ISO/IEC/IEEE 42010 (ISO 2011)相關(guān)的通用模板的實用方法。

4.實際考慮

如上所述，邏輯架構(gòu)模型的目的是提供系統(tǒng)必須能夠做什么來滿足所述需求的描述。這將有助于確保所有利益攸關(guān)方的需求和/或關(guān)注點都能通過任何解決方案得到解決，并且能夠考慮創(chuàng)新的解決方案，以及基于當(dāng)前解決方案技術(shù)的解決方案。在實踐中，問題利益攸關(guān)方推動他們自己的議程，解決方案架構(gòu)師或設(shè)計師提供他們熟悉的解決方案，這是人的本性。如果邏輯架構(gòu)模型在選擇的生命周期中沒有得到適當(dāng)?shù)膱?zhí)行，那么問題和解決方案利益攸關(guān)方很容易忽略它，并恢復(fù)到他們自己的偏見(參見第5部分:啟用系統(tǒng)工程)。如果邏輯架構(gòu)模型成為其自身權(quán)利的終點，或者與主要生命周期活動斷開連接，這種情況就會加劇。這可以通過使用抽象語言或符號、細(xì)節(jié)級別、花費的時間或過于復(fù)雜的最終架構(gòu)來實現(xiàn)，而最終架構(gòu)與創(chuàng)建它的目的并不匹配。如果架構(gòu)的語言、范圍和及時性與問題利益攸關(guān)方或解決方案提供者不匹配，他們就很容易忽略它。下面兩部分將描述有助于避免與邏輯架構(gòu)模型相關(guān)的問題的關(guān)鍵缺陷和良好實踐。

4.1陷阱

表1提供了在開發(fā)邏輯架構(gòu)時遇到的一些關(guān)鍵缺陷。

表1。邏輯架構(gòu)開發(fā)的缺陷。

4.2實踐證明

表2提供了從參考資料中收集的一些經(jīng)過驗證的實踐。

表2。經(jīng)過驗證的邏輯架構(gòu)開發(fā)實踐。

原文標(biāo)題：邏輯架構(gòu)模型過程方法

文章出處：【微信公眾號：汽車電子硬件設(shè)計】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。

責(zé)任編輯：haq