臺灣博碩士論文加值系統

現今，車隊管理系統內，車子電腦的軟體更新都是透過車廠的專業人員來完成的手動完成的。由於目前尚未有一套完善的軟體更新機制，所以每一部車輛軟體的更新都必須透過車廠的專業技術人員來完成的。 在這篇論文中，我們提出一個動態可抽換的車隊管理系統架構，在這個系統架構下它結合了OSGi, OSCAR Bundle Repository(OBR) and service binder來支援遠端傳輸軟體元件。車隊管理系統的應用程式經由控制中心操作人員或是車機用戶端操作更新後不需要重新開機即可動態的完成更新。

These days, the software update in vehicle client is completed manually in fleet management systems. The rework of software update in every vehicle is done by factory skilled workers due to the absence of dynamic software update mechanism. In this thesis, we proposed a dynamic plugable fleet management system architecture, which combined the OSGi, OSCAR Bundle Repository (OBR) and service binder, to delivery software component. The fleet management applications need not to be restarted after software update which controlled by control center operator or vehicle client.

第一章 緒論 1
1.1 背景 1
1.2 動機 1
1.3 論文架構 2
第二章 背景知識介紹 3
2.1 OSGi介紹[1][2][5] 3
2.1.1 OSGi服務平台介紹 3
2.1.2 OSGi Bundle的介紹[1][2] 8
2.1.3 OSGi的優點 9
2.2 OSCAR介紹[17] 10
2.3 OBR [15] 11
2.4 Service Binder 的介紹 [9] 11
第三章 系統設計與實作 17
3.1系統功能需求分析 17
3.2系統架構 18
3.2.1系統服務的觀點 18
3.2.2系統功能觀點 24
3.3 系統劇本 31
3.3.1 Vehicle Dispatch Service 31
3.3.2 Dispatch Specific Vehicle 32
3.3.3 Cancel Vehicle Dispatch 33
3.3.4 Service Management 33
3.3.5 Update Service 34
3.3.6 Add Service 34
3.3.7 Remove Service 35
3.3.8 Vehicle Management 35
3.3.9 Add Vehicle Data 35
3.3.10 Modify Vehicle Data 36
3.3.11 Remove Vehicle Data 36
3.3.12 Search Vehicle Data 36
3.3.13 Vehicle Status Report 36
3.3.14 Emergency Notification Report 37
3.3.15 Display Traffic Information 38
3.3.16 Service Management for Service Provider 38
3.3.17 Search a specific vehicle 38
第四章 案例探討 40
4.1 Dynamic update map viewer by control center案例說明 40
4.2 Dynamic update vehicle service by driver案例說明 44
第五章 結論與展望 47
參考文獻 48
Appendix 50
Section 1 Introduction 53
1.1 Acceptance criteria of this document 53
1.2 Identification 53
1.3 Overview 53
1.4 Document Scope 54
1.5 Method 55
1.6 Notation 55
1.7 Controlling Documents 55
1.8 Requirement Priorities 56
Section 2 Fleet Management System (FMS 1.0.0) 56
2.1 System Description 56
2.2 Functional Requirements 57
2.3 Interface Requirements 59
2.3.1 Internal Interfaces 59
2.3.2 External Interfaces 60
2.4 Performance Requirements 60
2.5 Operational Concepts 60
2.5.1 Cancel Vehicle Dispatch service 77
2.5.2 Vehicle Dispatch Services 78
2.5.3 Vehicle Management Service 81
2.5.4 Search a Specific Vehicle Service 85
2.5.5 Dispatch a Specific Vehicle Service 86
2.5.6 Service Management for Administrator Service 89
2.5.7 Service Management for Service Provider Service 92
2.5.8 Vehicle Status Report Service 93
2.5.9 Emergency Notification Service 94
2.5.10 Display traffic information 95
2.6 Safety，Reliability and Maintainability Requirements 96
2.6.1 Safety Requirements 96
2.6.2 Reliability Requirements 97
2.6.3 Maintainability Requirements 97
2.7 Delivery，Installation，and Environmental Requirements 97
2.7.1 Delivery Requirements 97
2.7.2 Installation Requirements 97
2.7.3 Environmental Requirements 98
2.8 Design and Implementation Constrains 98
2.9 Test Requirements and Acceptance Criteria 98
2.9.1 Test Requirements 98
2.9.2 Acceptance Criteria 99
2.10 Technological limit 101
2.11 End User Issue 101
2.12 Risk management 101
2.13 Trace Matrixes 101
2.13.1 Functional Requirements and Functional Requirements Matrix 102
2.13.2 Interface Requirements and Functional Requirements Matrix 103
2.13.3 Performance Requirements and Functional Requirements Matrix 104
2.13.4 Interface Requirements and Interface Requirements Matrix 105
2.13.5 Performance Requirements and Performance Requirements Matrix 106
2.13.6 Interface Requirement and Performance Requirements Matrix 106
2.13.7 Requirements and Components Matrix 107
Section 3 Control Viewer (CVer 1.1.0) 109
3.1 Component Description 109
3.2 Functional Requirements 109
3.3 Interface Requirements 110
3.3.1 Internal interfaces 110
3.3.2 External Interfaces 110
3.4 Performance Requirements 111
Section 4 Fleet Dispatch (FD 1.2.0) 112
4.1 Component Description 112
4.2 Functional Requirements 112
4.3 Interface Requirements 113
4.3.1 Internal Interfaces 113
4.3.2 External Interfaces 114
4.4 Performance Requirement 114
Section 5 Traveler Viewer (TVer 1.3.0) 115
5.1 Component Description 115
5.2 Functional Requirements 115
5.3 Interface Requirements 115
5.3.1 Internal interfaces 115
5.3.2 External interfaces 116
5.4 Performance Requirements 116
Section 6 Fleet Monitor (FM 1.4.0) 117
6.1 Component Description 117
6.2 Functional Requirements 118
6.3 Interface Requirements 118
6.3.1 Internal interfaces 118
6.3.2 External interface 118
6.4 Performance Requirements 119
Section 7 Service Manager (SMer 1.5.0) 120
7.1 Component Description 120
7.2 Functional Requirements 120
7.3 Interface Requirements 121
7.3.1 Internal interfaces 121
7.3.2 External interface 121
7.4 Performance Requirements 122
Section 8 Driver Viewer (DVer 1.6.0) 123
8.1 Component Description 123
8.2 Function Requirements 123
8.3 Interface Requirements 124
8.3.1 Internal Interfaces 124
8.3.2 External Interfaces 125
8.4 Performance Requirements 125

[01] Open Services Gateway Initiative, “Official web site,” http://www.osgi.org, 2003.
[02] “Open Services Gateway Initiative”, OSGi Service Platform, Release 3.
[03] Sun Microsystems. JavaTM 2 Platform, Micro Edition. http://java.sun.com/j2me/.
[04] Hans Werner Pohl Jens Gerlach, “Fraunhofer Institute for Computer Architecture and Software Technology (FIRST) Using the Bridge Design Pattern for OSGi Service Update”. Berlin Germany
[05] 黃永順 李坤敏 吳文鈴 林文瑋, “OSGi 開放式服務平台技術家用閘道器與智慧型車輛之應用” 工業技術研究院 電腦與通訊工業研究所。
[06] Auburn Hills, Michigan “DaimlerChrysler Research and Technology” North America, Palo Alto, California Sun Microsystems, Southfield, Michigan DaimlerChrysler IT Cruiser Telematics Concept DaimlerChrysler Corporation
[07] “Microsoft Windows Update”, http://windowsupdate.microsoft.com
[08] IBM Corp., “Eclipse Platform Plug-in Developer Guide,” Online Whitepaper, 2000.
[09] Marcel ffermans. “Automatically managing service dependencies in OSGi.” January 7, 2005
[10] Jose L. Ruiz Juan C. Dueñas Fernando Usero Cristina Díaz “Deployment in dynamic environments”.
[11] H. Cervantes and R. S. Hall. “Automating Service Dependency Management in a Service-Oriented Component Mode”l, in the proceedings of ICSE CBSE6 Workshop 2003, held in Portland, USA.
[12] Humberto Cervantes and Richard S. Hall “Building Auto-Adaptive Applications With a Service-Oriented Component Model: Concepts and Experiences”.
[13] R. S. Hall and H. Cervantes, “Gravity: Supporting Dynamically Available Services in Client-Side Applications,” Poster paper in Proceedings of ESEC/FSE 2003, September 2003.

[14] H. Cervantes and R. S. Hall, “Beanome: A Component Model for the OSGi Framework,” Workshop on Software Infrastructures for Component-Based Applications on Consumer Devices, September 2000.
[15] Richard S. Hall, ” Oscar Bundle Repository “- Official Web Site. http://oscar-osgi.sf.net (2004)
[16] Richard S. Hall and H. Cervantes, “ An OSGi Implementation and Experience Report”. In: Proceedings of IEEE Consumer Communications and Networking Conference. (2004)
[17] Oscar Community, Official Web Site (2004) http://oscar.objectweb.org.
[18] The Eclipse Foundation: Eclipse Platform - Technical Overview. Technical report, Object Technology International Inc. (2003)
[19] Christian Ensel and Alexander Keller, “Managing Application Service Dependencies with XML and the Resource Description Framework”.
[20] Alessandro Orso, Anup Rao, and Mary Jean, “ A Technique for Dynamic Updating of Java Software”.
[21] Sun Microsystems, Java 2 Platform API Specification.
http://java.sun.com/j2se/1.3/docs/api/.
[22] Michael Hicks、Jonathan T. Moore and Scott Nettles, “Dynamic Software Updating”.
[23] E. C. Nelson, K. V. Prasad, V. Rasin, C. J. Simonds, “An embedded architectural framework for interaction between automobiles and consumer devices”, Ford Motor Company
[24] Alexandre Saad, BMW Car IT GmbH, Munich, “Java-based Functionality and Data Management in the Automobile”. Prototyping at BMW Car IT GmbH. /Germany