新產品協同開發之案例式推理系統

(1)

摘

摘要

要

現今瞬息萬變的環境中，新產品開發的時間不斷的縮短。而新產品對國家可以提高生產力、競爭力與經濟成長力，對企業最主要可以創造利潤、提高競爭力與形象提升等，可說新產品對國家與企業的發展影響甚鉅。如今的產業已經不像以往，單打獨鬥就可以生存下去。因此，從最早產品資料管理產品開發，而後加入協同與產品資料等理念之後，發現新議題。就是資料量日漸龐大，案例搜尋變成一大困擾之外，公司與公司之間合作頻繁，傳統的案例式推理只能用在同一家公司，這方式已經無法配合協同公司。針對此一問題，本研究除利用案例式推理方式，而後再加上協同理念配合開發新產品環境，畢竟這已是現今企業合作生產的一項重要議題。

本論文將案例式推理系統（ Case-Based Reasoning System, CBRS ）結合協同設計（Collaborative Design）的理念，開發出可以運用於新產品協同開發之案例式推理系統。為運用 Internet 將協同開發團隊結合，本文利用 Java 程式結合來達到跨平台之協同案例式推理之目標。本案例式推理系統植基於產品資料管理系統（Product Data Management System, PDMS），於案例式推理系統中篩選出的案例可以由 PDMS 下載相關設計資料。藉由選擇本公司或協同公司中的新產品開發之專案資料庫的歷史專案，可以縮短並且改善新產品開發之流程與品質。本研究之主要研究議題為 CBR 協同作業機制與安全控管機制的建立，以增進協同公司間產品開發的效率並且能保持公司的智慧財產。關鍵詞關鍵詞關鍵詞關鍵詞：：：：新產品開發新產品開發新產品開發、新產品開發、協同設計、、協同設計協同設計、協同設計、、案例式推理、案例式推理案例式推理案例式推理

1. 前

前

前言

前

言

當進入二十一世紀之初，在這快速變遷的時代，「彈性」與「速度」成為製造業進入 21 世紀賴以生存的決勝關鍵。由於企業的競爭越來越激烈，為了增加市場競爭力，實有必要推行協同設計（Collaborative Design），藉以縮短產品生命週期，使產品能儘早上市，佔得先機。

(2)

首先是將協同設計的理念應用於軟體工程中，亦即是提出一協同設計於軟體發展之方法，在此方法論下提出一整合性之產品資料管理架構（Product Data Management Framework, PDMF）與案例式推理（Case-based Reasoning, CBR）來實現軟體產品協同開發速度與效能提昇之目標。

1.1 新新新產品開發程序新產品開發程序產品開發程序 產品開發程序

新產品開發活動是指產品由概念形成至上市銷售的一連串步驟或是行為，不同的產品因為性質不同而步驟也會有所調整。根據 Cooper[1]的研究，新產品發展流程可以劃分為產品構想（idea）、初期評估（preliminary）、概念設計（concept）、產品發展（development）、產品測試（testing）、工程試產（trial）、及量產上市七個階段。Vroom[2]則以零件設計製造業為對象，建構了一個發展流程模式，而文中明確的定義出一般性的作業活動與架構，且設定產品發展流程是由概念發展（concept development）做為起點，而量產（production starting point）成為產品發展流程的最終點。綜此，我們將產品設計分為六個階段：概念形成、初步設計、細部設計、雛形、設計驗證、生產階段，如圖 1 所示。圖 1 新產品設計步驟 1.2 新新新產品新產品產品協同產品協同協同開發協同開發開發開發根據 Gartner Group[3]指出，2000 年開始，企業應用資訊科技的演進已經從 1995 年的企業內系統，1995 年至 2000 年的價值鏈/供應鏈整合的資訊系統以及電子商務演進至目前的協同商務時代。從早期的企業資源規劃（Enterprise Resource planning, ERP）、與企業流程再造（Business Process Re-engineering, BPR），其重點在於企業內部資訊的整合，卻忽略了外部整合的重要性。到了 90 年代初期，企業才逐漸將重心轉移至整合外部上下游廠商之間的運作，此時發展出供應鏈管理（Supply Chain Management, SCM）。協同產品商務（Collaborative Product Commerce）是在於產品的整個生命週期當中，透過運用資訊科技與技術[4, 5]，建立一特定之價值鏈，以降低地域與群聚效應之影響，進而分享其技術與經驗，來達成產品研發、設計、製造等協同合作之目的，如圖 2 所示。協同產品設計的概念著重於以下幾點：

1. 針對產品生命週期來設計，可以獲取企業資訊與未來發展目標為何？ 2. 利用 WEB 的模式來整合與協同資訊科技。

(3)

圖 2 協同產品開發概念圖 1.3 案例式推理案例式推理案例式推理（案例式推理（（（CBR））））案例式推理法（Case-Based Reasoning；簡稱 CBR）是人工智慧領域中重要的一個範疇，是仿效人類應用先前經驗解決問題的方法學[6]。Schank 和 Abelson [7]在 1977 年時提出以 Script 模式模擬人類的知識記憶意思就是說將人以前的技藝或經驗模擬成一個 Script，假使要認識新的事物時，再將類似的 Script 拿出來做參考，用來解釋此新的事物，如圖 3 所示。而後 Schank[8]所提出的動態記憶為基礎的後續發展，他所被重視的原因為案例式推理不同於其他人工智慧方法必須具備相關問題領域的知識，而案例式推理卻能夠利用過去相似問題個案累積的經驗中推導出相關知識，應用重複相關問題於新問題上。使用案例式推理系統，於找到相似的案例與解答之後，可以依 CBR 的形式進行改編（Adapt）或論證（Justify）等行為，假如是問題解決型的 CBR，則可以採用改編、解釋型的 CBR 可採用論證，接著再進行評論（Criticize），如圖 4 所示[9]。這三步驟是可以互相遞回的，直到找出合適的解答為止。案例式推理應用於新產品設計，其最主要步驟有四點：

(4)

1. 案例的取回（Case Retrieval）：從案例庫中搜尋相似案例，以提供新問題解決方法的建議。新產品開發流程上，也就是在案例庫中搜尋是否具有符合顧客要求的新產品存在於案例庫中 2. 案例的再使用：符合新問題要求的案例，即可重覆的使用，迅速解決顧客的問題。 3. 案例的調適（Case Adaptation）：若現存的案例無法完全滿足現有的需求，則需要加以適當的調適，以符合新問題的要求。以產品設計而言，現存於案例庫中的案例無法完全滿足顧客的規格，需要修改由案例庫中取出的歷史設計案例。 4. 案例保留：調適後的經過評估後將被存入案例庫中，案例資料可不斷地累積儲存，隨著案例的增加，所得的結果將更為準確。問題描述 Problem 案例比對 Mapping 案例擷取 Retrieve 目標案例輸入 Target Case Entry

案例儲存 Store 案例索引 Case Index 案例修正 Modify 案例測試 Test 案例蒐集 Gather Case 相似度之定義 Similarity Definition 案例資料庫

Case Base Library

案例 Case

YES

NO

(5)

圖 4 案例式推理（CBR）流程圖

2. 協同運作之資訊安全控管

協同運作之資訊安全控管

因為目前網際網路已非常盛行，再加上公司機密和文件必須有所控管與保護，所以權限與安全性這方面已經非常受到注目與研究，而目前比較熱門有關安全性的探討可分為三種：一是自由裁量的執行管制（Discretionary Access Control, DAC）、一是強制性的執行管制（Mandatory Access Control, MAC）、一是植基於角色的執行管制（Role-based Access Control， RBAC），分為三小節加以探討。

2.1 自由裁量存取控制自由裁量存取控制自由裁量存取控制（自由裁量存取控制（（（Discretionary Access Control））））

就是使用者身份及特殊的規則，來給予不同物件（Object），對不同物件有不同存取方式（如：讀取、寫入或執行），使用者每次對物件有存取的需求時，應根據先前制訂做檢查，同時使用者只有在被認可的狀況下，他的存取行為才能被接受進入，否則應予以拒絕進入本系統或拿取資料[15][16]。DAC 的存取控制較具彈性，跟下一節所要講的 MAC 來比，DAC 具有更多的變化性與彈性，來依照系統及程式的需求作調整。可是 DAC 也有小缺點，像是假使允許 A 讀取 B 的權力，而 A 不須經過 B 就可以授權 C 來讀取 B 的能力，對於權限傳遞控制並不能有效控制（見圖 5），這點 MAC 就可以避免相同的方式發生，因為 DAC 是靠使用者本

(6)

身給予授權，如需改善必須要再定義另外授權方式，防止授權給另一方，而導致資料或機密的外洩。

圖 5 Discretionary Access Control

2.2 強制存取控制強制存取控制強制存取控制（強制存取控制（（（Mandatory Access Control））））

強制存取控制的存取方式是建立在有分類（Label）的主體（Subject）與物件（Object）的系統上，也就是說明每一個主體及物件在系統中都會在指定在安全層（Security Level）裡，每一安全層中物件連結被認可的資訊，並給予主體使用能力。因為所有的物件與主體的安全等級設定都是由管理者來決定。MAC 它具有階層（Hierarchical）的架構，以圖 6 說明在安全層下的物件與主體存在一定的權力關係，所以 MAC 提供兩個資料存取原則來因應不同需求 [15][16]分別是 Read Down（上層的 Subject 可以讀取下層的的 Object）；

Write Up（下層的 Subject 可以寫入上層的 Object）和 Read Up（下層的 Subject 可以讀取上層的的 Object）；Write Down（上層的 Subject 可以寫入下層的 Object）兩種模式。第一種模式（見圖 6）原則是在防止在較上層將重要的資訊經由寫入較下層的方式，而把資訊給外洩出去。第二種模式（見圖 7）是在防止下層儲存欲往上層傳遞的資訊。

(7)

圖 6 Mandatory Access Control 方法一

圖 7 Mandatory Access Control 方法二

2.3 強制存取控制強制存取控制強制存取控制（強制存取控制（（（Mandatory Access Control））））

在企業或公司中，職位或角色的定義是相當明確並且容易管理的，所以利用角色為基礎的存取控制，可以使使用者分配到適當的角色，而資源的存取權限則是經由所屬的角色來決定。RBAC 基本架構具備五個主要元件，包括使用者（User）：直接與系統有互動行為的人或程式、Session：使用者對應至可使用的角色集合（Active Role Set）的過程、角色（Role）：可以視為組織或存取控制機制中扮演的角色，描述使用者對應到此角色可被賦予的權限、權力（Permission）：指存取機制中對於物件的權力，包括存取方式或一些操作行為等及限制（Constraint）：規定角色彼此的關係，如階層關係、角色互斥關係等[11]。如圖 8 說明角色與角色之間可以是階層式的關係，就如同一家公司中，每個人因職務上的不同，扮演不同種類的角色，而彼此之間形成一種階層式的關係，又稱樹狀關係。關係好比樹狀，位於最上方具有最高階的權力，上層可以繼承下層的權限或權利，稱之為角色階層（Role Hierarchy），最上層的董事長就可以擁有全部的能力，再來總經理就少董事長一階能力，但是在他之下的角色他通通擁有，越往下層，權限能力越低，所看到或使用功能也就越少，這種繼承的關係如同實際組織的架構，因此 RBAC 利於管理。另外當然有一些角色的某些權力不希望被繼承，所以 RBAC 在角色繼承上定義了另一種方式，就是利用角色階層的方法，先作角色的定義，之後就可以方便存取控制的管理[12]。

(8)

圖 8 Role-based Access Control

3. 協同式

協同式

協同式 CBR 的系統架構

協同式

的系統架構

有關於協同式的概念架構，依目前的協同型態模式，大約可以分為兩種比較重要且具代表性的，分別是集中式協同及分散式協同二種模式，所謂的集中式協同，就是透過該產業具有領導地位的企業（組織）領導發展而產生的，為了希望達成某些目的，而與相關之企業（組織）透過協同商務之架構，來達成目的，而分散式協同和集中式最大的差異就是企業（組織）間因為共同目的之需要，以平等原則所發展出來，此類稱為分散式協同，以目前研究的方向會集中研究有關分散式協同模式[13]。 3.1 協同作業流程與架構協同作業流程與架構協同作業流程與架構 協同作業流程與架構針對分散式協同作業，以供應鏈上三個公司來的協同開發作業為例，分別是 A 公司（代表目前 USER 正在這家公司）、B 和 C 公司（Supplier B & Supplier C），協同案例式推理系統（CCBRS）架構如圖 9 所示。當一使用者使用 A Company 的內網上公司（企業）的內部網站，查詢資料與下載相關檔案，會先利用 Web Interface（Portal Site）進入內部提供協同機制的網頁，透過 CBR 搜尋模式（CBR Core）與 CBR 的案例庫（CBR Library）兩者互相傳遞資訊，之後依照想要搜尋之特徵值輸入到搜尋頁面後，就可以搜尋到公司內部或外部（連結到 B 或 C 公司）找尋相關零件規格或檔案等資料。當然在這協同的過程中會探討有關安全性考量（Collaboration Service: Collaborative Access Management）、權限控管（Security Service）與實作技術層面的應用，該如何相互配合與整合以上所說明的各項單元模組，來達成協同機制理念，節省互相溝通與交涉反覆所花的繁瑣過程與時間，減少新產品在設計研發甚至製造所花的時間，提早在市場上曝光，搶得上市時機已增加獲利機會，這就是協同機制最主要的理念。

(9)

Collaborative Case-Based Reasoning System (CCBRS) 圖 9 協同案例式推理系統（CCBRS）架構 3.2 CBR 核心流程核心流程核心流程 核心流程隨著資訊業快速發展，產品週期越來越短，品質卻是要求相對提高，而產品製程更加複雜。這就是為什麼往往搜尋後會花上許多時間在挑選適合的相關案件或檔案，甚至以往的電腦資料都是存在一個或數個沒經過分類的資料夾裡，這樣的結果當然是在尋資料時會花上大半時間再作有關相似度方面的判別，而 CBR 對於案例的分類與判別都別有於以往的比對模式，所以要增快速度勢必不能再用傳統的方式，以圖 10 與圖 11 分別說明兩種情況：第一種是在內部利用 CBR Core 來搜尋內部公司裡的案例資料庫（Case Library）。第二種情況是利用協同觀念來搜尋外部公司裡的案例資料庫。

內部使用者使用內部公司的 CBR 系統，在 CBR Core 依照案件索引（Case Index）或打入關鍵字搜尋特徵值，回傳到內部公司的案例庫來找尋相類似案例，之後作相似度比對後排列於相似度高到低，列表排列出相關案例，選擇欲下載之項目就會回傳到案例庫找尋案例存放處，執行下載傳輸之行為等等。

(10)

圖 10 CBR Core 流程圖：內部圖 11 說明外部人員，利用公司內網與協同機制連到 B 和 C 公司，經過安全機制控管，進入到各公司的 CBR Core 進行案例搜尋與比對排列，傳回排列過的案例列表與相關資訊，經過確認哪幾筆資料後，傳回欲下載列表相關資訊後，經過 WEB SERVICE 處理後，傳回有關案例連結至 PDM 相關檔案與可下載明細，經過選取需要下載或想要得到哪些相關資料後，傳回協同公司，經過協同那端處理之後，傳回至使用者一個下載檔案，下載至使用者端，完成協同資訊取得，這些資料就可提供 A 公司人員做設計或製造的參考依據，過程完全不用透過 B 或 C 公司人員在檔案提供與找尋方面或者是溝通上的困擾，而且安全部分都有加入考量與管理限制，所以在這繁瑣過程中，大大的提升作業速度與效率，不過缺點就是要使同步關聯性的資料型態，在未來可加入 XML 或者其他格式方面的交換機制，就可以增加系統的相容性與資料轉化。

(11)

(12)

3.2 協同式協同式協同式 CBR 安全控管協同式安全控管安全控管安全控管

協同最需要考量的就是安全性方面的問題，在設計協同部分，分為內、外部兩方面來說明。首先是內部方面，如圖 12 當要登入 A 公司內部網站時（Web Interface），必須先要登入 User Name 和 Password 來進入，等身分確認無誤之後，就可以針對登入者所扮演的角色，來進行內部權限控管，最主要控管有關於功能性方面；而 Collaboration Service: Collaborative Access Management（CAM）最主要的是要判斷安全性分類，可以針對外部使用者 B 進入公司網站或給予一個 Request 時，根據登入身份與 IP 兩者交互確認，決定是否可以進入協同廠商 A 的內部網路。而進入時針對四種層級分別為供應商（Supplier）、零售商（Retailer）、內部（Internal）和全部開放（Open Up），分別跟使用者 B 的權限能力來決定開放程度到哪種層級，之後再進入到 CBR Core 進行案例的搜尋來完成想要得到的資訊，回傳到 B 公司，或者第二種情形是針對 B 公司要 C 公司的資訊（兩者互相知道或許互相不知道）。但是因為協同的關係，B 公司會透過 A 公司而去跟 C 公司 Request，而 C 公司會比對此項 Request 是否開放層級為全部開放，如果是的話就會回傳列表案例於 B 公司，再決定是否確定要下載此類資料與檔案，如果不是屬於層級(4)的話，就不會回傳列表於 B 公司網頁，也就是資訊不會因為公司 B 利用公司 A 就可以輕易獲得公司 C 的資訊（假使 B 和 C 兩者關係並不知情下）。

Collaborative Case-Based Reasoning System (CCBRS)

(13)

Wide Web），透過內部網路使用者介面來針對協同廠商做連結與資訊存取於案例庫等相關程序與步驟，詳細資料如下表 4-1。

本研究之案例庫系統是建構在各個協同公司內部資料庫的架構下，藉著網際網路的廣泛性、即時性、互動性，以便利使用者即時獲取有用且相似度頗高的資訊，而系統是以內部網路使用瀏覽器為客戶端（client side）使用介面，透過網路伺服器（web server）與伺服器端的資料庫產生聯繫與互動或者針對協同廠商提出請求或回應，達到資訊彼此間的交流或互動。資料庫系統（Database System）分為兩個主要部分所構成，分別為資料庫（Database）與協同案例資料庫管理系統（CDBMS）。資料庫方面是存取一些內部公司系統運作的一般資料，例如產品結構、PDM、基本資料、專案資料等等，而協同案例資料庫管理系統則是一組管理有關案例方面的應用與相關程式等，如圖 13 所示。表 4-1 系統運作環境表設備名稱配備需求網頁瀏覽器 Internet Explorer 7 網站伺服器 Apache Tomcat 5.5 程式語言 JAVA、Javascript、XML 資料庫管理系統 MySQL 5.0 圖 13 資料庫（DB）、案例庫（CDB）與協同案例資料庫管理系統（CDBMS）關聯圖

(14)

4.2 系統系統系統實作範例系統實作範例實作範例 實作範例 4.2.1 系統登入系統登入系統登入系統登入 首先必須先利用管理者新建開放一筆新成員資料，好讓新的成員能夠在首頁利用同仁專區進入登入畫面（圖 14），利用管理者給一組帳號和密碼登入，登入後進入系統首頁（圖 15），選取上方功能列之基本資料模組，進行基本資料的新建與維護並更改帳號和密碼，以上完成後就可以正常使用本系統。圖 14 Login 畫面圖 15 系統首頁

(15)

圖 16 產品模組結構樹狀圖 4.2.3 CBR 與與與與 Case Library 之建構之建構之建構 之建構基本來說 CBR 的架構需要隨著產品架構變化而做調整，以方便多種類產品可以同時由單一的 CBR 控管。為達到此一目標，本系統建構一 CBR 資料結構表，其作業循序圖如圖 17 所示。根據 CBR 資料結構表再進一步建構案例庫（Case Library），利用物件導向（Object-Oriented）的方式把案例分別放入適當的類別中；而圖 18 說明如何把案例放入適當的案例類別中，利用物件搜尋特徵值的方式，就可以避免不必要或者相差太多的案例出現在案例列表中，有別於關鍵字搜尋或無物件導向觀念的方式，搜尋出來的案例多又相關性不高，而物件式搜尋出來的案例少但較準確，提供給想要找尋案例的人減輕不少選擇與過濾方面的麻煩。圖 19 大致上建構流程跟產品模組差不多，為了是要讓 CBR 建立物件模組觀念，讓案例放在正確的物件模組下，以上畫面說明新增、修改、刪除和查詢等功能如何執行與運作。圖 20 的畫面說明把案例放到物件式案例庫內有哪些功能可執行與執行時的流程程序畫面等。

(16)

圖 17 建構 CBR 資料結構表之循序圖

(17)

(18)

圖 20 物件式案例庫的建置程序與功能選項流程畫面

5. 結論與建議

結論與建議

本研究乃藉由案例式推理（Case-Based Reasoning, CBR）與協同理念兩者之應用並透過相似度的特徵值，讓開發設計者有其概念性之開發設計架構，且產品設計不需經手經驗很充足的人員，一般開發成員都可以利用此系統獲得他們想知道的訊息與資料，省去翻紙本或者

(19)

未來研究針對開發設計作業之流程改善做探討，如何將其兩者以上的不同開發設計環境結合起來。而 CBR 目前在研究領域中已經有很明顯且很成熟的討論，在案例套用上成效也不錯，所以大略說明其研究後續發展之可能： 1. 協同部分資料轉換格式與介面呈現之考量研究，針對環境、背景不同的公司如何利用網際網路作為溝通或擷取資訊的橋梁，而且更加自動化與人性化。 2. 案例式推理在應用上多使用在工程方面之研究，其管理方面較無互相之探討；針對此部份可將工程應用研究結合以專案為考量依據，管理者可以針對專案成員之績效評比來做更深一層的發展與探討。

誌

誌謝

謝

本研究承蒙國科會（計畫編號：NSC95-2221 E-151-003）經費上的支持，特此表達感謝。

參考文獻

[1] Cooper, R.G., “A process Model for Industrial New Product Development,” IEEE Transactions on Engineering Management, 1983, vol. 30, No. 1, pp. 2-11.

[2] Vroom, R. W., “Metamodel to chart the product and process design, evaluated in automotive supplier companies”, Proceedings of the 5th International Conference on Flexible Automation and Intelligent Manufacturing (FAIM’95), 1995, Stuttgart, Germany.

[3] Burdick, D., B. Bond, D. Miklovic, K. Pond, and C. Eschinger, C-Commerce：The New Arena for Business Applications, 1999, Gartner Group Research Note.

[4] Carroll, Mike, “Collaborative Commerce: The Next Big Thing in Global Manufacturing,” eAI Journal, 2001, p. 20, July.

[5] Klaas, O. and M.S Shepard, “Embedding Reliable Numerical Analysis Capabilities into an Enterprise Wide Information System”, Engineering With Computers, 2001, vol. 17, No. 2, pp.151-161.

[6] Watson, I. and F. Marir, “Case-Based Reasoning: A Review”, The Knowledge Engineering Review, 1994, Vol.9, No.4, pp.355-381.

(20)

[7] Schank, R. C. and R. P. Abelson, Scripts, Plans, Goal and Understanding Erlbaum, 1977, Lawrence Erlbaum Associates, Hillsdate, NJ, USA.

[8] Schank, R., Dynamic Memory: A Theory of Learning in Computers and People, 1982, Cambridge University Press, New York, USA.

[9] Kolodner, J., Case-Based Reasoning, 1993, Morgan Kaufmann Publishers, San Francisco, USA .

[10] Gollmann, Dieter, Computer Security, 1999, John Wiley & Sons, New York, USA.

[11] Sandhu, R. S. and E. J. Coyne, “Role-based Access Control Models”, IEEE Computer, 1996, February, pp.38-47.

[12] Chen, T.Y., Y.M. Chen, H.C. Chu, and C.B. Wang, Development of an access control model, system architecture and approaches for resource sharing in virtual enterprise. Computers in Industry, 2007, Vol. 58, No. 1, pp. 57-73.

[13] 毛立青，協同商務之研究─以TFT-LCD產業為例，2003，元智大學資訊管理學系，碩士論文。