1.目的

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

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

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

2.過程的活動

在此過程中執行的主要活動和任務包括:

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

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

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

將系統需求分配到功能和行為要素:

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

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

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

為每個候選項定義候選邏輯架構模型:

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

集成這些功能場景，以獲得系統的行為架構模型(動態行為的完整描述)。

根據需要分解前面定義的邏輯要素，以查看實現。

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

為與決策級別相對應的功能定義多個級別的執行頻率，以便監控系統操作，在這個時間基礎上對處理進行優先級排序，并在這些執行頻率級別之間共享功能，以獲得一個當前架構模型。

執行功能失效模式和效果分析，并根據需要更新邏輯架構要素。

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

集成選擇的獨立邏輯架構模型:

通過根據評估標準(與系統需求相關)評估候選邏輯架構模型并對它們進行比較，選擇邏輯架構，使用系統分析過程來執行評估和選擇的決策管理過程(參見系統分析和決策管理主題)。這種選定的邏輯架構模型稱為獨立邏輯架構模型，因為它盡可能地獨立于實現決策。

識別和定義為設計的必要性而創建的與派生的系統需求相對應的派生的邏輯架構模型要素。將這些需求分配給適當的系統(當前研究的系統或外部系統)。

驗證并驗證所選擇的邏輯架構模型(盡可能使用可執行的模型)，根據需要進行修正，并建立系統需求和邏輯架構模型要素之間的可追溯性。

反饋邏輯架構模型開發和系統需求。此活動在物理架構模型開發過程之后執行:

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

定義或合并由所選邏輯和物理架構模型產生的派生邏輯和物理要素。定義相應的派生需求，并將它們分配到適當的邏輯和物理架構要素。將這些派生的需求合并到受影響系統的需求基線中。

3.工件、方法和建模技術

邏輯架構描述使用分組在下列模型類型下的建模技術。已經開發了幾種方法來支持這些類型的模型(有些是可執行模型):

功能模型——包括結構化分析設計技術(SADT/IDEF0)、系統分析與實時(SA-RT)、增強功能流框圖(eFFBD)和功能分析系統技術(FAST)等模型。

語義模型——包括實體關系圖、類圖和數據流圖等模型。

動態模型——包括狀態轉換圖、狀態圖、eFFBDs、狀態機等模型

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

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

4.實際考慮

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

4.1陷阱

表1提供了在開發邏輯架構時遇到的一些關鍵缺陷。

表1。邏輯架構開發的缺陷。

4.2實踐證明

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

表2。經過驗證的邏輯架構開發實踐。

原文標題：邏輯架構模型過程方法

文章出處：【微信公眾號：汽車電子硬件設計】歡迎添加關注！文章轉載請注明出處。

責任編輯：haq