產品全生命週期的產品結構和配置管理構架
摘要 : 詳細敘述了產品全生命週期產品結構和配置管理的概念、產品結構和配置管理系統的物件關係邏輯模型及其物理實現構架。
現代社會是一個崇尚個性化消費的社會,人們在選購產品時,除了注重產品基本功能、效能外,往往還會提出一些個性化要求。全世界許多大型製造業企業正面臨大規模的產品製造與提供個性化的產品和服務之間的矛盾。
顯然,基於網際網路的資訊系統為解決這樣的矛盾提供了可能,電子商務可以在企業和消費者之間建立起一種資訊的橋樑,然而,產品的資訊貫穿於整個產品的設計、工藝規劃、生產製造、採購與銷售、售後服務過程,而且在這一過程中,產品又是處在不斷改進和適應市場的變化之中,所以,如何保證產品資訊傳遞的及時、可靠是實現真正意義上的電子商務的基礎。於是,資訊領域的專家提出面向產品全生命週期的產品資訊管理 ( Product Information Overall Lifecycle Management , PLM ) 的概念,將以前面向產品設計部門的產品資料管理系統提升為為整個企業的生產經營服務的資訊系統。
貫穿於產品全生命週期的產品結構與配置管理系統是 PLM 完整解決方案的關鍵技術之一,同時也是其他許多系統 ( 如 ERP , CRM ) 需要的基本資訊服務。本文將系統描述產品結構和配置管理系統的概念以及該系統核心部分的邏輯設計,然後結合當今一些熱門的開發技術提出該系統在構架上的選擇方案。
1 產品結構和配置管理系統的概念設計
結構和配置是對產品資訊進行組織和管理的一種形式,它以網路資料庫為底層支援,以物料明細表 ( Bill o f Material , BOM ) 為其組織核心,將用於描述產品的設計、工藝、製造的工程資料和文件聯絡起來,實現對產品資訊的組織、管理和控制,並在一定目標或規則的約束下,向不同的使用者或應用系統提供產品結構的不同檢視和描述。
1.1 產品結構的管理
產品結構是對產品構成的描述。企業的許多資訊資源中均顯式或隱式地包含產品結構資訊,如設計工程圖中的裝配圖、裝配明細表;工藝檔案中的裝配工藝規程;產品維護文件及使用者手冊中的產品裝配爆炸圖 ( 形象地表達產品的裝配過程或檢修過程 ) 等。
管理產品結構具有兩個方面的目的:一方面,以產品結構為組織框架,可以很方便地對所有產品相關資訊進行管理,有利於產品資訊的組織和查詢;另一方面,基於產品結構能提供統一的有關產品構成的資訊描述,同時可以根據產品生命週期不同階段的需要,提供有側重點的資訊服務。
為了達到上述目的,產品結構管理一般採用檢視控制法,在某個產品結構的不同使用場景中,透過各種不同劃分方法進行管理和描述。每個檢視是一個管理物件,檢視物件間可以根據一定的規則進行構件資訊和結構資訊的傳遞。每個構件可以與多個檢視相關聯,這樣便能從同一個產品結構產生不同的檢視。
例如,在產品設計時,設計人員產生了面向功能模組的設計檢視;在進行工藝過程規劃時,工藝人員在設計檢視的基礎上,加入工藝方面的相關資訊,可以產生一個面向製造和裝配的工藝檢視;生產製造部門又可以在工藝檢視的資訊基礎上,結合生產的實際情況,透過資源的最佳化組合,產生一個面向製造的檢視;採購人員根據需要,在製造檢視的基礎上,可以產生關於外購件的採購檢視;售後服務人員根據需要,可以產生面向技術支援和服務的維護檢視。圖 1 是產品結構多檢視轉換示意圖。
圖 1 產品結構的多檢視轉換
1.2 產品配置的管理
產品配置是同產品結構緊密相關的概念。按照國際標準 ISO10007 對配置管理的基本定義,配置是指對被描述在技術文件中或者體現在產品實際使用過程中的產品功能特性和物理特性所作的表示。這是從產品特性的角度對產品配置進行定義,相當於客戶和銷售部門使用的配置概念。例如某 PC 電腦的配置是 P Ⅲ 800 , 256M 記憶體, 40G 硬碟,我們稱之為配置需求。
由於對產品的特性需求最終是透過實際的產品結構來實現的,因此產品配置的結果是具體的產品結構檢視。例如 PC 電腦最終的配件清單,我們稱之為配置結果。
另外,配置也被看成是一個選擇一組構件並維護其關係以形成一個設計解決方案來解決客戶需求的過程,這時配置的概念相當於配置過程。配置的以上 3 種概念,是對配置這一概念從不同角度的理解,同時也是本管理系統進行邏輯設計的出發點之一,見圖 2 。
圖 2 產品配置的使用示意
2 產品結構和配置管理系統的邏輯模型
產品結構管理模型和產品配置管理模型之間有著緊密的聯絡。從產品結構角度看,涉及零部件的層次關係、零部件的版本以及零部件物件與描述零部件物件的產品資料的關聯問題;從產品配置角度考慮,會涉及有關有效性、配置項及其多檢視管理的問題。
2. 1 產品製造單元的層次化結構關係
層次式的產品結構劃分方法指出了一個產品的零部件在設計方面和功能方面的聯絡。零件和部件是產品結構中的兩個基本的構成物件,是產品設計工作的基礎資料,其中包括產品開發過程中所需要的關於某個物品的重要資訊。對於零件,產品結構表示了該零件所使用的製造資源或半成品。
製造資源既包括製造產品所需的材料,也包括製造產品所需的裝置,甚至包含製造產品所需的工時等資訊。利用製造資源和半成品物件,可以將工藝過程規劃和採購方面的資訊加入到產品結構中,使得產品結構資訊更加完整,其應用範圍也會更廣,這樣才能使產品結構資訊在整個產品生命週期內都具有指導價值。
零件和部件物件間存在 n : m 的關係;同時,零件和原材料、半成品物件間也存在 n : m 的關係。這類關係為結構關係,見圖 3 。
圖 3 結構關係描述模型
2. 2.2 產品製造單元的版本資訊
一個零件或部件可以有多個版本,這些版本是隨著時間的推移,因排除問題或進行產品改進而形成的。零部件物件採用版本標記對零部件的版本進行區分。與版本無關的屬性,如物品編號或名稱等,在所有的零部件物件中始終不變。為了支援產品結構與配置管理中的版本管理,將零部件的屬性分成與版本有關和與版本無關兩種屬性,即完整描述一個零部件的資訊需用到兩類資料,稱之為零部件類和零部件唯一標識類。零部件唯一標識物件將與版本無關的各種屬性動態地傳送給相應的與版本有關的零部件物件。
一個零件、部件、製造資源或半成品都可以有多個版本,所以各自的唯一標識類和與版本有關的各類間存在 1 : n 的關係。圖 4 為唯一標識關係類模型。
圖 4 唯一標識類模型
製造單元的版本的組織有 3 種形式:
·鏈式版本關係。對於物件各版本透過生成的先後順序進行管理和維護,能反映版本之間的時間先後關係。
·樹狀版本關係。透過版本物件的繼承、派生關係來組織物件各版本,能追溯每個版本的產生來源。在樹狀版本關係中,我們假定每個版本只能從一個父物件上派生。
·網狀版本關係。如果考慮每個版本能從多個父物件上派生,那麼該版本關係將在樹狀版本的基礎上生成網狀的版本關係。
2.3 產品製造單元的互換關係
產品結構分解中出現的產品零部件唯一標識物件之間存在著替換和互換的關係,這種關係稱之為替換關聯資訊和互換關聯資訊,表徵了企業中經常用到的互換件和替換件的關係。製造資源、半成品唯一標識物件間存在的關係類為替換關聯類和互換關聯類,描述了零件生產中出現的製造資源或半成品唯一標識類之間存在替換和互換的關係,在企業中通常表現為可以互換的材料或可以互換的製造裝置等關係。物件之間的這種可替換關係往往被一些條件約束。圖 5 為互換關聯模型。
圖 5 互換關聯模型
2.4 產品製造單元的配置
為了快速、自動地實現在眾多的、複雜的互換或替換關係中選擇合適的產品製造單元,從而形成完備且必要的產品結構資訊,必須提供配置過程處理和配置資訊的管理。可以在系統中新增配置條件物件、配置規則物件和配置處理物件。配置條件物件是對配置需求的一種抽象,它將使用者對產品可能提出的配置需求分類,不同的分類又可有不同的取值。在不同的分類變數之間,使用者可以定義與、或、非的關係。圖 6 為配置條件模型。
圖 6 配置條件模型
配置規則物件是對產品結構配置規則集的抽象。首先,配置規則物件是建立在具體的可互換標識物件之上的,實際上是對可互換標識物件的互換規則說明。每個配置規則物件是一些配置規則項物件的集合,每個配置規則項物件包含所引用的配置變數物件在某個取值狀態下可選的唯一標識物件集合。圖 7 為配置規則物件模型。
圖 7 配置規則物件模型
配置處理物件是對配置過程的一種抽象,配置處理物件接受某個可互換標識物件作為輸入條件,以某個配置規則物件集作為支援條件,受到某個配置條件物件和產品結構檢視型別的控制,最後產生一個產品結構的檢視物件為配置結果。圖 8 為配置處理功能圖 ( IDEF0 ) 。
圖 8 配置處理功能圖
圖 8 所示配置處理功能圖的表示形式最初出現在美國空軍 ICAM ( Integrated Computer Aided Manufac - turing ) 工程在結構化分析方法的基礎上發展的一套系統分析和設計方法中,稱為 IDEF 方法 ( ICAM defini - tion method 的縮寫 ) 。 IDEF0 是 IDEF 的第一部分,用於描述功能模型。
3 產品結構與配置管理系統的物理構架
( 1 ) 從系統的可用性角度考慮。
由於該系統所解決的問題貫穿於產品的全生命週期,系統的使用可能是跨地域的,所以該系統必須構架在一種分散式的網際網路體系平臺上。
系統的某些功能集中在一個部門中使用,如產品結構檢視的維護,一般在企業的設計和工藝部門使用;有些功能又需要跨地域使用,例如產品結構的查詢,可能被各種不同的使用者或與之整合的其他資訊系統使用。所以該系統必須能同時支援同步處理和非同步處理功能,能適應連線資料環境和非連線資料環境的使用狀況,並支援大事務的處理。
由於系統的使用終端平臺可能是不同的,如何支援跨平臺的程式部件呼叫是一個值得注意的問題。
( 2 ) 從系統的效能角度考慮。
由於產品結構資料的伸縮性比較大,有些產品可能只由幾個零部件組成,有些產品則由成千上萬個零部件組成,加上製造資源和半成品資料,一個完整的產品結構資料可能是海量的。所以系統對底層的資料庫支撐平臺的伸縮性要求比較強,最好能從資料庫底層解決資料庫的分散式問題,同時系統的執行部件在部署時也可能是分佈的。
( 3 ) 從系統的可維護性角度考慮。
由於系統可能比較龐大,所以系統必須使用統一的容錯、報錯處理機制,特別是對於一些服務部件必須提供必要的錯誤恢復機制。在選擇開發技術時,有必要對該技術對於上述機制的支援能力加以分析。此外,系統的升級應該是容易和快速的。
( 4 ) 從資訊整合的角度考慮。
從兩個方面來考慮整合:第一,要對本系統提供的服務進行粗粒度的、元件化的封裝,便於以較少的工作量實現動態整合;第二,與其他系統的整合應該是松耦合的。
為了滿足以上要求,我們選擇了兩種技術方案作為該系統的構架。
a. J2EE( Java ( tm ) 2P latform , Enterprise Edi - tion ) 的解決方案
J2EE 是一個以 Java 技術為基礎的多層應用程式構架,也是被眾多廠商支援的一種技術規範和平臺。 J2EE 的體系結構見圖 9 。
圖 9 J2EE 的體系結構
從圖 9 可以看出,元件化的系統實現方案的優勢幾乎在 J2EE 都有體現, J2EE 中的 EJB 元件 ( Enter - prise Java Beans ( tm ) Components ) 是用來處理業務邏輯的關鍵;資料訪問部件 JDBC ( Java Database Connec - tion ) 用於訪問資料庫;事務處理部件 JTA ( Java Trans - action Management Application ) 用於處理大的事務,並保證事務的原子性;訊息處理部件 JMS ( Java Message Server ) 用於處理訊息,以支援非同步的資訊處理,滿足在不持續的網路連線環境中的資訊處理。
由於 J2EE 採用 Java 技術作為基礎技術,所以能很好地支援跨平臺,對系統的安全有比較全面的考慮,這是 J2EE 的優勢,同時 J2EE 是一種開放的體系結構,所有的底層技術都可對外公開,這對於注重資訊保安的金融系統和航空、航天以及其他國防部門而言是一個好的選擇。
b. .Net Framework 的解決方案
.Net Framework 是微軟最新的解決分散式網路應用的一種構架 ( 圖 10 ) ,可以認為是對 WinDnA ( Windows Distributed N etwork Application ) 的全面改造和升級。 .Net Framework 與 J2EE 比較類似。
圖 10 .Net Framework 的應用解決方案
.Net Framework 的顯著特點是提出了一種 CLR ( Common Language Runtime ) 的概念,它提供了一套更可靠的程式碼執行管理機制和執行環境,同時從理論上解決了 .Net Framework 跨平臺的問題。同 J2EE 相比, .Net Framework 還可以保持一種程式語言的中立,換句話說, .Net Framework 支援多種程式語言,只要編譯器將原始碼翻譯為 Microsoft 中間語言 ( MSIL ) 即可, MSIL 是一組可以有效地轉換為本機程式碼且獨立於 CPU 的指令。微軟推薦使用 C # 語言作為 .Net Framework 的開發語言。 .Net Framework 的優勢在於開發工具的多樣性和開發效率比較高。
同 J2EE 一樣, .Net Framework 支援 Web 服務, Web 服務是一種分散式的計算模式,它是粗粒度的,又是松耦合的,見圖 11 。 Web 服務由於使用超級文字傳輸協議 HTTP ( s ) ,所以可以穿過防火牆; Web 服務透過使用擴充套件標記語言 ( XML ) 的後設資料 ( Meta data ) 描述內容,並透過通用的目錄服務來查詢。
圖 11Web 服務的工作示意圖
這樣的一個 Web 服務技術方案,滿足瞭解決本系統要考慮的所有基本技術問題。可以認為,面向產品全生命週期的產品結構和配置系統不僅能作為一個軟體產品來為某些大企業、大集團服務,甚至可以作為一種 Web 形式的資訊服務平臺來向大多數中小企業提供。
4 結束語
在用資訊化來改造傳統工業的過程中,資訊化產業本身面臨一種挑戰,即資訊化產業的工業化。目前,有些資訊化企業片面追求大而全的發展思路,這阻礙了資訊化產業的進一步細分,不能充分發揮各企業在各自領域的專業優勢。我們相信,在一種整體整合方案構架下的專業服務系統,是資訊化帶動工業化的發展過程中的新生力量,它將帶動資訊化產業向更為合理的專業細分的方向發展。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31532639/viewspace-2641626/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 品牌生命週期和產品生命週期之間的關係
- TiPLM---產品全生命週期管理系統
- TRY/TRM — 產品全生命週期資料關聯和追溯
- PLM產品生命週期管理展望
- 寧波三品PLM產品全生命週期管理一體化方案
- 產品生命週期管理PLM技術研究
- 數字產品護照 (DPP) 解決方案:利用 Blazor 和區塊鏈實現產品全生命週期追蹤Blazor區塊鏈
- 綠色數字智慧主線——PLM產品生命週期
- 如何記錄產品和軟體架構決策?架構
- Oracle PLM,協同研發的產品生命週期管理平臺Oracle
- 阿里雲產品之資料中臺架構阿里架構
- 迎接“全全閃”時代 XSKY星辰天合發布星海架構和星飛產品架構
- 大型 SaaS 平臺產品架構設計思路架構
- 轉載] magento 產品資料表結構
- 2024最流行的網站架構----邊緣平臺架構:概念與產品網站架構
- 產品生命週期(PLM)發展歷程及技術核心分析指導
- Paradox管理團隊談新的產品戰略和結構轉型
- Maven 構建生命週期Maven
- 做一個有產品思維的研發:課程架構架構
- 揭秘LOL背後的IT基礎架構丨產品而非服務架構
- 【細品架構4/100】架構之架構切分架構
- 產品型公司的“偽產品”?
- 北京智和信通:IT資產全生命週期運維監控管理方案運維
- 芯原助力藍洋智慧部署基於Chiplet架構的晶片產品架構晶片
- 阿里雲資料中臺新品Quick Stock 助力貨品全生命週期管理阿里UI
- 我對《RAG/大模型/非結構化資料知識庫類產品》技術架構的思考、雜談大模型架構
- 淺析阿里雲API閘道器的產品架構和常見應用場景阿里API架構
- 產品經理如何做好產品和需求管理
- 談談如何使用資料產品畫布構建高價值資料產品
- 《解構產品經理》讀書筆記筆記
- 如何構建最小可愛產品(MLP)? - userpilot
- 一種基於事件驅動架構的 SAP 產品整合方案介紹事件架構
- 唯品會架構師是如何實現架構重構的架構
- Android官方架構元件Lifecycle:生命週期元件詳解&原理分析Android架構元件
- 新產品如何推廣?推廣新產品的方法和技巧
- 作為產品經理,如何分析和管理你的產品需求
- 石墨文件技術總監:敏捷思想在產品週期的延伸敏捷
- 產品功能 | BI產品替代Excel困難重重?Smartbi幫你全搞定!Excel