Nghiên cứu, phát triển và ứng dụng kiến trúc hướng mô hình để thi hành các hệ thống điều khiển công nghiệp

Để xây dựng một hệ thống phức tạp, người phát triển hệ thống phải trừu tượng hóa những khung nhìn View khác nhau của hệ thống, xây dựng các mô hình bằng cách sử dụng các kí hiệu một các

NGƯỜI HƯỚNG DẪN KHOA HỌC :

TS NGÔ VĂN HIỀN

Hà Nội – 2010

2

LỜI CAM ĐOAN

Luận văn này là kết quả của sự tìm hiểu và nghiên cứu của bản thân dưới sự hướng dẫn của Tiến sĩ Ngô Văn Hiền Những tài liệu và kết quả nghiên cứu sử dụng trong luận văn của các tác giả khác đều được trích dẫn nguồn gốc cụ thể theo quy định

Luận văn này cho đến nay chưa được bảo vệ tại bất kỳ một hội đồng bảo vệ luận văn thạc sĩ nào và chưa được công bố trên bất kỳ một phương tiện thông tin nào

Tôi xin cam đoan những gì tôi trình bày ở trên là hoàn toàn chính xác, nếu sai tôi xin hoàn toàn chịu trách nhiệm

Hà nội, ngày 20 tháng 10 năm 2010

Tác giả luận văn

Hoàng Đức Mẫn

3

MỤC LỤC

PHỤ LỤC BÌA……… ….1

DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT 5 

DANH MỤC CÁC BẢNG 6 

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ 7 

MỞ ĐẦU 9 

Chương 1- CÁC NGUYÊN TẮC MÔ HÌNH HÓA TRỰC QUAN VÀ CÁC ĐẶC TRƯNG TRONG CÔNG NGHỆ HƯỚNG ĐỐI TƯỢNG 11 

1.1 Tầm quan trọng của mô hình hóa 11 

1.2 Các nguyên tắc mô hình hóa trực quan 13 

1.3 Các đặc trưng trong công nghệ hướng đối tượng 14 

Chương 2- GIỚI THIỆU VỀ KIẾN TRÚC HƯỚNG THEO MÔ HÌNH VÀ HỆ THỐNG ĐIỀU KHIỂN CÔNG NGHIỆP 17 

2.1 Kiến trúc hướng theo mô hình 17 

2.1.1  Các mô hình trong MDA 17 

2.1.2  Sự chuyển đổi mô hình trong MDA 22 

2.2 Tổng quan về hệ thống điều khiển công nghiệp 27 

2.2.1  Phân loại các hệ thống điều khiển công nghiệp 27 

2.2.2  Tổng quan về cấu trúc của HDS 28 

2.2.3 Hệ thống động lực lai điều khiển công nghiệp 29 

2.2.4 Các điều kiện ràng buộc trong quá trình phát triển hệ thống điều khiển công nghiệp 30 

2.2.5 Đặc tả Automatlai để phát triển hệ thống điều khiển công nghiệp 32 

Chương 3- QUY TRÌNH PHÂN TÍCH VÀ THIẾT KẾ HDS CÔNG NGHIỆP VỚI MDA 34 

3.1  Phân tích kiến trúc hệ thống 34 

3.1.1  Tổng quan về kiến trúc hệ thống 34 

3.1.2  Xác định các tầng kiến trúc của hệ thống 35 

3.1.3  mô tả các cơ chế kiến trúc 36 

3.1.4  Sự tham chiếu các tầng kiến trúc với MDA 37 

4

3.2 Đặc tả tổng quan MDA cho HDS công nghiệp 38 

3.3 Quy trình chi tiết MDA cho HDS công nghiệp 39 

3.3.1  CIM của HDS công nghiệp 40 

3.3.2  PIM của HDS công nghiệp 48 

3.3.3  PSM của HDS công nghiệp 68 

Chương 4- ÁP DỤNG QUY TRÌNH MDA CHO HDS CÔNG NGHIỆP 71 

4.1 Mô hình CIM 72 

4.1.1  Các trường hợp sử dụng và các tác nhân 72 

4.1.2  Ứng xử động của các trường hợp sử dụng 73 

4.1.3  Sơ đồ khối chức năng của SCCS 77 

4.1.4  Automat lai của SCCS 79 

4.2 Mô hình PIM 83 

4.2.1 Các lớp thực thể và lớp biên của SCCS 83 

4.2.2 Sơ đồ thực thi các cộng tác đối tượng 84 

4.2.3 Cấu trúc và ứng xử động của các trường hợp sử dụng chính 85 

4.3 Mô hình PSM 87 

4.3.1  Các luật chuyển đổi từ PIM sang Matlab-Simulink (PSM) 87 

4.3.2  Các kết quả mô phỏng của SCCS với Matlab-Simulink 88 

KẾT LUẬN VÀ KIẾN NGHỊ 92 

5

DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT

Ký hiệu

BUS Business System Hệ thống nghiệp vụ

BPM Business Process Model Mô hình quy trình nghiệp vụ

CIM Computation Independent

Model

Mô hình độc lập với thao tác tính toán

CSDL Cơ sở dữ liệu Cơ sở dữ liệu

DAO Data Access Object Đối tượng truy xuất dữ liệu

MDA Model Driven Architecture Kiến trúc hướng theo mô hình MOF Meta Object Facility Khả năng siêu hướng đối tượng J2EE Java 2 Platform, Enterprise

Edition

Nền công nghệ java 2 phiên bản đầy đủ chức năng

EBP Elementary Business

Process Quy trình nghiệp vụ cơ bản HDS Hybrid Dynamic System Hệ thống động lực lai

IGCB Instantaneous Global

Continuous Behavior Ứng xử liên tục toàn cục tức thời

IEC61499 IEC - International Electrotechnical

OODBMS Object-Oriented Database

Language Ngôn ngữ mô hình hoá hợp nhất VOPC View Of Participating

Classes Khung nhìn về các lớp tham gia

DANH MỤC CÁC BẢNG

Bảng 3.1 Luật chuyển đổi các phần tử phân tích thành các phần tử thiết kế trong

mô hình PIM 62

7

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ

Hình 1.1 Tổng quan các đặc trưng trong công nghệ hướng đối tượng 15 

Hình 2.1 Sự phân loại các mô hình chính trong MDA 18 

Hình 2.2 Một ví dụ về phát triển hướng theo mô hình với kiến trúc phần mềm 19 

Hình 2.3 Ví dụ về CIM 20 

Hình 2.4 Ví dụ về PIM - dựa theo Hình 2.3 20 

Hình 2.5 Ví dụ về PSM - dựa theo Hình 2.4 với công nghệ J2EE 21 

Hình 2.6 Mô hình chuyển từ CIM sang PIM 22 

Hình 2.7 Chuyển đổi mô hình theo vết 23 

Hình 2.8 Quá trình biến đổi siêu mô hình 24 

Hình 2.9 Quá trình biến đổi mô hình 24 

Hình 2.10 Quá trình biến đổi theo ứng dụng mẫu 25 

Hình 2.11 Ví dụ tổng quát về quá trình biến đổi sử dụng tên mẫu 26 

Hình 2.12 Ví dụ về quy trình MDA cho một hệ thống phức tạp 27 

Hình 2.13 Sơ đồ khối tổng quan của HDS công nghiệp [9] 30 

Hình 3.1 Các tầng kiến trúc hệ thống 36 

Hình 3.2 Quy trình MDA thực thi hệ thống HDS công nghiệp 38 

Hình 3.3 Ví dụ về một sơ đồ chức năng mở rộng 40 

Hình 3.4 Ví dụ về các trừu tượng hóa chính 41 

Hình 3.5 Ví dụ về sơ đồ trường hợp sử dụng 42 

Hình 3.6 Sơ đồ diễn tiến của trường hợp sử dụng “Cấu hình hệ thống” tương với Hình 3.5 43 

Hình 3.7 Máy trạng thái của trường hợp sử dụng “Cấu hình hệ thống » 44 

Hình 3.8 Cấu trúc tổng quan về CIM của HDS công nghiệp 47 

Hình 3.9 Sơ đồ lớp của cộng tác đối tượng phần rời rạc 48 

Hình 3.10 Sơ đồ lớp của cộng tác đối tượng phần liên tục 49 

Hình 3.11 Sơ đồ lớp của công tác đối tượng IGCB 50 

Hình 3.12 Sơ đồ lớp của cộng tác đối tượng giao diện bên trong 51 

Hình 3.13 Sơ đồ lớp của cộng tác đối tượng giao diện bên ngoài 52 

Hình 3.14 Sơ đồ kết nối thực thi của HDS 52 

Hình 3.15 Ví dụ một lớp biên “CauHinhForm” 55 

Hình 3.16 Ví dụ một lớp điều khiển “CauHinhControl” 56 

Hình 3.17 Ví dụ một lớp thực thể “PI” 57 

Hình 3.18 Ví dụ việc mô tả thuộc tính của lớp thực thể “PI” 58 

Hình 3.19 Ví dụ một Sơ đồ diễn tiến thể hiện mối quan hệ giữa các lớp phân tích trong chức năng “Thay đổi cấu hình hệ thống” 60 

8

Hình 3.20 Sơ đồ các lớp phân tích tham gia trường hợp sử dụng “Cấu hình hệ

thống” 61 

Hình 3.21 Ví dụ sự chuyển đổi các lớp phân tích thành các lớp thiết kế 63 

Hình 3.22 Ví dụ về các thành phần của một hệ thống con 67 

Hình 3.23 Mô hình kiến trúc thiết kế ứng dụng với nền công nghệ hướng đối tượng 69 

Hình 4.1 Mô hình giải pháp tổng quát chức năng hoạt động của SCCS 71 

Hình 4.2 Mô hình trường hợp sử dụng của SCCS 73 

Hình 4.3 Sơ đồ diễn tiến của trường hợp sử dụng “ Bảo trì” 74 

Hình 4.4 Sơ đồ diễn tiến của trường hợp sử dụng “ Theo dõi” 74 

Hình 4.5 Máy trạng thái của trường hợp sử dụng “Theo dõi” 75 

Hình 4.6 Sơ đồ diễn tiến của trường hợp sử dụng “ Bảo vệ”- IPS bị lỗi 75 

Hình 4.7 Sơ đồ diễn tiến của trường hợp sử dụng “ Bảo vệ” - SCCS bị lỗi 76 

Hình 4.8 Máy trạng thái của trường hợp sử dụng “Bảo vệ” 76 

Hình 4.9 Máy trạng thái tổng quát của SCCS 77 

Hình 4.10 Sơ đồ khối chức năng của SCCS 78 

Hình 4.11 Automat lai của SCCS với các sự kiện bên trong Eii 82 

Hình 4.12 Automat lai của SCCS với các sự kiện bên trong Eii 83 

Hình 4.13 Các lớp thực thể đối với các dòng liên tục 83 

Hình 4.14 Lớp giao diện bên trong 84 

Hình 4.15 Lớp giao diện bên ngoài 84 

Hình 4.16 Sơ đồ cấu trúc thực thi PIM của SCCS 85 

Hình 4.17 Sơ đồ diễn tiến thể hiện mối quan hệ tương tác giữa các lớp phân tích trong “Chức năng theo dõi” của trường hợp sử dụng “Theo dõi”……… 86

Hình 4.18 Sơ đồ tổng quan các lớp phân tích tham gia trường hợp sử dụng “Theo dõi……… 87

Hình 4.19 Sơ đồ kết nối tổng quan giữa các hệ thống con trong mô hình PSM của hệ thống SCCS……… 88

Hình 4.20 Mô hình các phần tử của phần liên tục trong hệ thống SCCS………….89

Hình 4.21 Vận tốc Camera 1 khi khởi động hoặc khởi động lại……… 90

Hình 4.22 Vận tốc Camera 2 khi khởi động hoặc khởi động lại……… 91

9

MỞ ĐẦU

Trong kỷ nguyên công nghệ và nền kinh tế đa chiều, việc phát triển các hệ thống công nghiệp có một vai trò quan trọng trong quá trình công nghiệp hóa, hiện đại hóa đất nước Hệ thống điều khiển công nghiệp là một phần của lĩnh vực sản xuất công nghiệp; nó ngày càng được nhiều doanh nghiệp sử dụng và phát triển để góp phần tạo ra giá trị cạnh tranh

Phương pháp tiếp cận kiến trúc hướng theo mô hình (MDA: Model-Driven Architecture) do tổ chức quản trị đối tượng quốc tế (OMG: Object Management Group) phát triển, để ứng dụng trong việc phát triển các hệ thống thông tin nói chung và các hệ thống điều khiển công nghiệp nói riêng MDA cho phép tách các đặc tả chức năng của một hệ thống độc lập với các đặc tả thực thi chức năng trên một nền công nghệ cụ thể Do đó, các đặc tả chức năng hệ thống có thể được sử dụng lại để thực thi trên các nền công nghệ khác nhau MDA giúp chúng ta thực hiện ba mục tiêu cơ bản là khả năng di động, tính xuyên chức năng và sự sử dụng lại thông qua việc tách rời các mối liên quan Do vậy, phương pháp tiếp cận kiến trúc hướng theo mô hình cho phép đáp ứng các yêu cầu luôn luôn thay đổi và tính phức tạp ngày càng tăng cao của hệ thống điều khiển công nghiệp

Chính vì vậy tôi chọn đề tài: “Nghiên cứu, phát triển và ứng dụng kiến trúc hướng mô hình để thi hành các hệ thống điều khiển công nghiệp” để cập nhật, nâng

cao kiến thức khoa học trong lĩnh vực điều khiển nói chung và trong chuyên ngành

cơ khí động lực nói riêng

Luận văn này được thực hiện nhằm mục đích nghiên cứu và áp dụng cách tiếp cận kiến trúc hướng mô hình nhằm đưa ra mô hình kiến trúc, phân tích, thiết kế

và mô phỏng các hệ thống điều khiển công nghiệp phức tạp có sử dụng automate lai

Nội dung luận văn được trình bày bởi các phần chính sau:

Chương 3: Quy trình MDA với hệ thống điều khiển công nghiệp

Chương 4: Áp dụng MDA cho việc phân tích hệ thống điều khiển cầu thang cuốn theo dõi qua camera quay

Để nghiên cứu đề tài này chúng tôi sử dụng phương pháp nghiên cứu lý thuyết và minh họa việc áp dụng lý thuyết nghiên cứu vào việc phát triển hệ thống thực tế Các mô hình phân tích thiết kế được thể hiện trên ngôn ngữ mô hình hóa hợp nhất UML và cách tiếp cận MDA Chúng tôi phân tích thiết kế một số trường hợp sử dụng quan trọng của hệ thống điều khiển cầu thang cuốn bằng camera quay

để minh họa cho phương pháp MDA được trình bày chi tiết trong chương 4 của luận văn này

Sau cùng, tôi xin trân trọng cảm ơn các thầy, cô giáo của Viện Cơ khí Động lực – Trường đại học Bách Khoa Hà Nội đã dạy dỗ, tạo điều kiện cho tôi trong thời gian qua; ban giám hiệu Trường Cao đẳng nghề Hà Nam, những người thân trong gia đình, bạn bè, đồng nghiệp đã luôn tạo điều kiện cho tôi về thời gian, vật chất và tinh thần để tôi có thể hoàn thành chương trình học Đặc biệt là TS.Ngô Văn Hiền,

là thầy giáo đã nhiệt tình hướng dẫn, giúp đỡ tôi rất nhiều trong quá trình làm luận văn, thầy đã cung cấp cho tôi các tài liệu tham khảo quý giá, thiết thực cho quá trình nghiên cứu đề tài luận văn

11

Chương 1- CÁC NGUYÊN TẮC MÔ HÌNH HÓA TRỰC QUAN VÀ CÁC

ĐẶC TRƯNG TRONG CÔNG NGHỆ HƯỚNG ĐỐI TƯỢNG

1.1 Tầm quan trọng của mô hình hóa

Mô hình hóa [2], [3] là cách đặc tả một bài toán thông qua việc sử dụng các

mô hình Mô hình dùng để hiểu rõ bài toán, trao đổi thông tin giữa những người hoặc hệ thông liên quan như khách hàng, chuyên gia, người phân tích, người thiết

kế v.v Mô hình giúp cho việc xác định các yêu cầu nghiệp vụ tốt hơn, thiết kế rõ ràng hơn và khả năng bảo trì hệ thống cao hơn

Mô hình là sự trừu tượng hóa, mô tả mặt bản chất của một vấn đề hoặc một cấu trúc phức tạp bằng cách loại bỏ những chi tiết không quan trọng, khiến cho bài toán trở nên dễ hiểu và dễ nắm bắt hơn Trừu tượng hóa là một khả năng cơ bản của con người trong việc giải quyết các vấn đề phức tạp Các kỹ sư, kiến trúc sư, các nghệ sĩ đã từng xây dựng những mô hình từ hàng nghìn năm nay để thử các thiết kế của họ trước khi thực hiện chúng Để xây dựng một hệ thống phức tạp, người phát

triển hệ thống phải trừu tượng hóa những khung nhìn (View) khác nhau của hệ

thống, xây dựng các mô hình bằng cách sử dụng các kí hiệu một cách rõ ràng, cẩn thận, kiểm tra xem các mô hình đã thoả mãn các yêu cầu nghiệp vụ của hệ thống chưa và dần dần thêm vào các chi tiết để có thể chuyển đổi từ mô hình sang một công nghệ cụ thể

Mô hình hoá trực quan là một phương thức tư duy về vấn đề sử dụng các mô hình được tổ chức xoay quanh các hiện tượng trên thực tế Mô hình giúp chúng ta hiểu vấn đề, giao tiếp với con người hoặc các hệ thống có liên quan đến dự án phát triển Mô hình rất hữu dụng trong việc đặc tả, trực quan, lập tài liệu và thiết kế hệ thống phát triển cũng như ngân hàng dữ liệu của nó Mô hình cho phép quản lý các yêu cầu nghiệp vụ của hệ thống tốt hơn, tạo các bản thiết kế rõ ràng hơn và xây dựng triển khai hiệu quả nên các hệ thống dễ bảo trì hơn [4]

Mô hình hóa là phần trung tâm trong các hoạt động để dẫn tới xây dựng được môt hệ thống điều khiển tốt Chúng ta xây dựng mô hình để trao đổi, thảo luận về

cấu trúc và ứng xử (behavior) mong muốn của hệ thống nhằm có được chất lượng

điều khiển hợp lý và hiệu năng cao Mô hình cũng cho phép kiểm soát kiến trúc và ứng xử của hệ thống [1]

 Sau khi xây dựng mô hình, chúng ta sẽ đạt được 4 mục đích sau:

- Mô hình giúp chúng ta trực quan hóa hệ thống như là nó vốn có hoặc theo ý tưởng của chúng ta

- Mô hình cho phép chúng ta chỉ rõ cấu trúc và ứng xử của hệ thống

- Mô hình cho chúng ta một khuôn mẫu để hướng dẫn trong quá trình xây dựng hệ thống

- Mô hình đưa ra các báo cáo bằng tài liệu về các tác tạo đưa ra trong quá trình phân tích và thiết kế hệ thống

Tùy thuộc vào đặc tả nghiệp vụ của hệ thống, mỗi mô hình có thể tập trung vào những mặt khác nhau của hệ thống Như hệ thống tập trung vào dữ liệu thì các

mô hình về phần thiết kế tĩnh của hệ thống sẽ được chú ý hơn Trong hệ thống giao diện với người dùng hoặc tương tác với các hệ thống liên quan, thì phần tĩnh và động của nó là quan trọng Trong hệ thống điều khiển công nghiệp như là: hệ thống thời gian thực, hệ thống nhúng, hệ thống động lực lai, thì các mô hình tiến trình động là quan trọng

13

1.2 Các nguyên tắc mô hình hóa trực quan

Mô hình hoá trực quan là việc sử dụng các ngôn ngữ thiết kế có tính chất đồ

hoạ và các mô tả ngắn gọn để thể hiện các bản thiết kế hệ thống, ví dụ: ngôn ngữ

mô hình hoá hợp nhất (UML) [2], [3], [18] Mô hình hóa trực quan cho phép trừu tượng hoá các hệ thống ở mức cao hơn, trong khi đó vẫn duy trì được ngữ nghĩa và cấu trúc căn bản của hệ thống, giúp cho người đọc bản phân tích và thiết kế dễ nắm bắt cấu trúc tĩnh và ứng xử động của hệ thống Mô hình hoá trực quan có bốn nguyên tắc cơ bản [2], [20]như sau:

Nguyên tắc 1: Các mô hình được tạo ra chi phối sâu sắc đến cách tiếp cận

và định hướng giải quyết một vấn đề

Trong phát triển hệ thống điều khiển, việc chọn các mô hình có thể ảnh hưởng rất lớn đến thế giới quan của người làm hệ thống Mỗi thế giới quan sẽ dẫn tới một loại mô hình khác nhau với chi phí và lợi ích khác nhau Nếu xây dựng hệ thống theo con mắt của người thiết kế cơ sở dữ liệu, kết quả nhận được sẽ là mô hình quan

hệ thực thể nêu ra cách xử lý trong các thủ tục lưu trữ và các trigger Nếu xây dựng

hệ thống thông qua con mắt của người phân tích thiết kế hướng đối tượng, kết quả đầu ra sẽ là một hệ thống có kiến trúc xoay quanh nhiều lớp và mẫu tương tác với nhau, điều khiển các lớp đó làm việc với nhau

Các mô hình tối ưu sẽ làm chi tiết những bài toán phát triển hệ thống phức tạp, giúp cho người phát triển hệ thống không bị sa lầy vào những vấn đề không cần thiết Một mô hình không tối ưu sẽ làm cho người phát triển dễ bị lạc hướng vì tập trung vào những vấn đề không liên quan

Nguyên tắc 2: Mỗi mô hình được thể hiện ở mức độ chi tiết khác nhau

Mỗi mô hình được chọn ở các mức chi tiết khác nhau tùy thuộc vào việc ai là người sử dụng mô hình và tại sao cần sử dụng mô hình

Ví dụ: Người sử dụng sử dụng khung nhìn trường hợp sử dụng (Use Case View) để biết hệ thống có đáp ứng được yêu cầu nghiệp vụ của nó không, người

14

phân tích thiết kế sử dụng khung nhìn logic (Logical View) trong quá trình phân tích thiết kế hệ thống, người triển khai sử dụng khung nhìn triển khai (Deployment View) để chuẩn bị môi trường cho việc triển khai v.v…

Nguyên tắc 3: Các mô hình chính xác nhất là các mô hình được liên hệ trong thực tế

Tất cả các mô hình đều là sự đơn giản hoá của thực tế Một mô hình chính xác

sẽ phản ánh đầy đủ những đặc trưng không thể thiếu về cấu trúc tĩnh và động của hệ thống và không che lấp đi bất kỳ một chi tiết quan trọng nào Mô hình vật lý của một hệ thống cũng có thể không được đáp ứng trên thực tế do bị hạn chế về nguồn tài nguyên và kinh phí Vì vậy, mỗi mô hình khi xây dựng cần được xem xét và đặt trong cơ sở hạ tầng thực tế

Nguyên tắc 4: Không có một mô hình đơn lẻ nào là đầy đủ Một mô hình tối

ưu nhất phải được tiếp cận thông qua một tập các mô hình độc lập tương đối với nhau

“Độc lập tương đối” có nghĩa là các mô hình có thể được xây dựng và xem xét độc lập nhau, nhưng chúng vẫn phải có mối quan hệ tương quan với nhau

Ví dụ: Để hiểu cấu trúc của một hệ thống hướng đối tượng điều khiển, những

người phát triển hệ thống cần kết hợp xem xét trên một số khung nhìn: khung nhìn

trường hợp sử dụng, khung nhìn logic, khung nhìn xử lý (Process View), khung nhìn thực thi (Implementation View), khung nhìn triển khai Mỗi khung nhìn được

xây dựng từ những góc nhìn khác nhau để thể hiện cấu trúc và ứng xử của hệ thống Chúng cùng nhau tạo nên một bản thiết kế đầy đủ, chi tiết cho một hệ thống

1.3 Các đặc trưng trong công nghệ hướng đối tượng

Công nghệ hướng đối tượng [2], [3] bao gồm một tập các nguyên tắc hướng dẫn xây dựng phần mềm nói chung hay phần mềm điều khiển trong công nghiệp nói riêng với các ngôn ngữ, các cơ sở dữ liệu và các công cụ hỗ trợ cho các nguyên tắc

đó Có bốn đặc trưng cơ bản trong công nghệ hướng đối tượng (Hình 1.1) như sau:

15

Hình 1.1 Tổng quan các đặc trưng trong công nghệ hướng đối tượng

Đặc trưng 1: Tính trừu tượng hoá (Abstraction)

Tính trừu tượng hoá cho phép người phát triển ứng dụng giải quyết những bài toán phức tạp bằng cách bỏ qua hay không chú ý đến một số khía cạnh chi tiết của thông tin để tập trung vào các đặc trưng cốt yếu của một thực thể; các đặc trưng làm thực thể đó nổi bật so với tất cả các thực thể khác Trừu tượng hoá phụ thuộc vào phạm vi và ngữ cảnh, những gì quan trọng trong ngữ cảnh này có thể không quan trọng trong một ngữ cảnh khác

Đặc trưng 2: Tính đóng gói (Encapsulation)

Tính đóng gói cho phép ẩn dấu phần thực thi của các tính năng (các thuộc tính

và các ứng xử) theo cơ chế hộp đen, thông qua giao diện dùng chung

Tính chất này không cho phép người sử dụng hoặc hệ thống tương tác tới các đối tượng thay đổi trạng thái nội tại của một đối tượng, mà chỉ có các phương thức nội tại của đối tượng mới được phép thay đổi trạng thái của nó Người sử dụng hoặc

hệ thống tương tác có thể sử dụng các thao tác, các thuộc tính mà không cần biết bên trong đối tượng được thực thi như thế nào Việc cho phép môi trường bên ngoài tác động lên các dữ liệu nội tại của một đối tượng theo cách nào là hoàn toàn tùy thuộc vào người phát triển hệ thống Nếu phần giao diện của tính năng nào đó

16

không bị thay đổi, người phát triển có thể thay đổi phần thực thi mà không cần thông tin lại cho người sử dụng hoặc hệ thống tương tác bên ngoài

Đặc trưng 3: Tính mô đun hoá (Modularity)

Mô đun hoá là tính chất cho phép chia một mô đun lớn và phức tạp thành một tập các mô đun con và đơn giản hơn để xử lý Các bài toán này có thể được phân tích, thiết kế, thực thi độc lập và sau đó được tích hợp với nhau thành một hệ thống lớn thông qua các giao diện của các mô đun con, để xử lý toàn bộ vấn đề

Mô đun hoá làm cho một hệ thống dễ dàng hơn trong việc thiết kế, thực thi, bảo trì và nâng cấp sau này, cũng như thuận lợi hơn cho việc tái sử dụng các thành phần đã phát triển Các mô đun của một hệ thống có thể được thực thi, gỡ bỏ, kích hoạt, vô hiệu hóa thông qua hệ thống quản lý mô đun

Đặc trưng 4: Tính phân cấp (Hierarchy )

Cấu trúc chung của một hệ thống hướng đối tượng là sự phân cấp các thành phần theo các mức độ trừu tượng hoá như phân cấp lớp, phân cấp thừa kế, phân cấp đặc tả v.v Các thành phần ở cùng một mức phân cấp thì nên tổ chức trong cùng mức trừu tượng hoá

Tóm lại, trong chương này chúng ta đã sơ lược về ý nghĩa và các nguyên tắc của mô hình hóa trực quan và các đặc trưng cơ bản của công nghệ hướng đối tượng Nó được sử dụng xuyên suốt trong qui trình phân tích, thiết kế và thực thi các hệ thống thông tin nói chung cũng như hệ thống điều khiển công nghiệp nói riêng Nhưng để phân tích và thiết các hệ thống điều khiển công nghiệp phức tạp, chúng ta sẽ đề cập kiến trúc hướng theo mô hình và tổng quan về hệ thống điều khiển công nghiệp trong phần tiếp theo

17

Chương 2- GIỚI THIỆU VỀ KIẾN TRÚC HƯỚNG THEO MÔ HÌNH VÀ

HỆ THỐNG ĐIỀU KHIỂN CÔNG NGHIỆP 2.1 Kiến trúc hướng theo mô hình

2.1.1 Các mô hình trong MDA

Kiến trúc hướng mô hình (MDA: Model-Driven Architecture) [8], [15] là một

cách tiếp cận mô hình hoá trực quan trong suốt quá trình tìm hiểu, phân tích, thiết

kế, thực thi một hệ thống phần mềm nói chung, đặc biệt là trong điều khiển công nghiệp Một số ứng dụng quan trọng về MDA trong điều khiển công nghiệp về lĩnh vực hàng không, tàu thủy đã được mô tả trong [16]

MDA phân chia các mô hình đặc tả về hệ thống từ mức độ trừu tượng hóa cao cho đến mức chi tiết và cung cấp các luật chuyển đổi cho phép chuyển đổi giữa các

mô hình

 Các mô hình chính của MDA bao gồm:

- Mô hình độc lập với thao tác tính toán (CIM: Computation Independent Model) thể hiện hệ thống ở mức nghiệp vụ

- Mô hình độc lập với nền công nghệ (PIM: Platform Independent Model) đặc

tả các chức năng hệ thống nhưng độc lập với các nền công nghệ thực thi hệ thống

- Mô hình theo nền công nghệ cụ thể (PSM: Platform Specific Model) đặc tả

các chức năng hệ thống theo một nền công nghệ cụ thể được lựa chọn để thực thi hệ thống

Hình 2.1 mô tả một cách tổng quan về sự phân loại các mô hình chính của MDA theo trật tự từ mức độ trừu tượng hóa đến cụ thể hoá

18

Hình 2.1 Sự phân loại các mô hình chính trong MDA

MDA được xây dựng dựa trên nguyên tắc phát triển hướng theo mô hình Các

mô hình này cho phép kiểm soát các hoạt động thiết kế và xây dựng của một ứng dụng thông qua sự chuyển đổi mô hình và các mẫu cụ thể

 MDA được xây dựng với ba mục đích chính: tính linh hoạt, khả năng xuyên chức năng và sự sử dụng lại, cho phép tạo ra khả năng thích nghi với các phát triển ứng dụng công nghiệp:

- Tính linh hoạt: cho phép cùng một kết quả được thực hiện trên nhiều nền công nghệ khác nhau hoặc trên một nền công nghệ mới

- Khả năng xuyên chức năng: dùng để tạo ra các hệ thống có thể tích hợp và liên hệ một cách dễ dàng với các hệ thống khác; hơn nữa, các hệ thống đó có thể sử dụng được những ứng dụng nguồn khác nhau

- Tính sử dụng lại: cho phép sử dụng một cách có kế thừa trong rất nhiều ứng dụng khác nhau trong những ngữ cảnh khác nhau

Hình 2.2 trình bày ví dụ về một quá trình phát triển phần mềm điều khiển công nghiệp theo kiến trúc hướng mô hình

19

Hình 2.2 Một ví dụ về phát triển hướng theo mô hình với kiến trúc phần mềm

2.1.1.1 Mô hình độc lập với thao tác tính toán (CIM)

CIM [8], [15] được xem như là mô hình nghiệp vụ hoặc lĩnh vực phát triển liên quan mô tả hệ thống ở mức cao nhất về cấp độ trừu tượng Mục tiêu cơ bản của CIM là dùng để mô hình hóa toàn bộ vấn đề của hệ thống trong ngữ cảnh nghiệp vụ, không đi vào giải pháp hoặc làm thế nào có thể thực thi được vấn đề đó

Hình 2.3 sử dụng sơ đồ lớp của UML nhằm đưa ra một ví dụ cụ thể của CIM Trong mô hình này không có thông tin nào chỉ ra giải pháp dựa trên thao tác tính toán

20

Hình 2.3 Ví dụ về CIM

2.1.1.2 Mô hình độc lập với nền công nghệ (PIM)

PIM [8], [15] được các nhà thiết kế sử dụng để mô tả giải pháp ở mức độ trừu tượng cao, độc lập với nền công nghệ dùng để triển khai giải pháp đó Tiếp theo, khái niệm về mức độ trừu tượng cao của giải pháp này có thể được chuyển sang các

mô hình cụ thể của các nền công nghệ khác nhau

Hình 2.4 sử dụng sơ đồ lớp của UML nhằm giới thiệu ví dụ về PIM xuất phát

từ ví dụ về CIM được mô tả trên hình 2 3 Mô hình này đã tiến gần tới việc thực thi, nhưng nó không gắn chặt với một nền công nghệ nào cả Ở đây, một nền công nghệ đích đối với hệ thống phần mềm điều khiển có thể là một trong nhiều các yếu

tố sau: một hệ thống điều hành cụ thể, một vi xử lý tính toán cụ thể, một ngôn ngữ lập trình cụ thể, hoặc là một thư viện mã cụ thể

Hình 2.4 Ví dụ về PIM - dựa theo Hình 2.3

21

2.1.1.3 Mô hình theo nền công nghệ cụ thể (PSM)

PSM [8], [15] đặc tả sự kết hợp giữa các thông tin được xác định trong PIM với một nền công nghệ cụ thể Nó thể hiện làm thế nào để một giải pháp có thể được thực thi trên một nền công nghệ mà chúng ta lựa chọn tối ưu nhất

Hình 2.5 sử dụng sơ đồ lớp của UML nhằm chỉ ra ví dụ về PSM xuất phát từ

ví dụ về PIM được mô tả trên Hình 2.4.Trong mô hình này, PSM đã thể hiện PIM của nó thông qua việc sử dụng các thuật ngữ và cấu trúc của một công nghệ cụ thể

đó là J2EE

Hình 2.5 Ví dụ về PSM - dựa theo Hình 2.4 với công nghệ J2EE

22

2.1.2 Sự chuyển đổi mô hình trong MDA

Sự chuyển đổi mô hình trong MDA [15] là việc sử dụng một cơ chế nhất định

để biến đổi các mô hình ở mức trừu tượng hoá cao thành các mô hình ở mức cụ thể

và chi tiết hơn dựa trên sự định nghĩa các luật chuyển đổi Đó là sự chuyển từ CIM sang PIM, từ PIM sang PSM, và từ PSM có thể chuyển thành mã chương trình cụ thể thực thi hệ thống Việc chuyển đổi giữa các mô hình có thể được thực hiện qua thao tác bằng tay, chuyển đổi tự động dựa vào các mẫu chuyển đổi khác nhau tuỳ thuộc vào những công cụ chuyển đổi và nền công nghệ đích, hoặc kết hợp cả hai phương thức Hiện nay, các công cụ hỗ trợ việc chuyển đổi mô hình trong MDA tập trung chủ yếu vào giai đoạn chuyển đổi từ PIM sang PSM, chỉ có một số ít cho phép chuyển đổi từ CIM sang PIM

2.1.2.1 Chuyển đổi từ CIM sang PIM

Mục đích của phần này chính là cách tiếp cận để chuyển đổi một CIM sang một PIM trong MDA Đầu tiên sử dụng sơ đồ hoạt động và diễn tiến trong UML2.x [3], [18] để xử lý các tác vụ của người sử dụng hoặc hệ thống có liên quan Sơ đồ hoạt động và diễn tiến này chỉ rõ các yêu cầu nghiệp vụ của hệ thống phát triển Các thành phần hệ thống được suy luận từ mô hình yêu cầu nghiệp vụ Cuối cùng, một

bộ các nguyên mẫu giúp các thành phần hệ thống tạo ra PIM Mô hình chuyển đổi tổng quan [3] từ CIM sang PIM được thể hiện trong Hình 2.6

Hình 2.6 Mô hình chuyển từ CIM sang PIM

23

2.1.2.2 Chuyển đổi từ PIM sang PSM

 Quá trình biến đổi theo vết mô hình

Hình 2.7 mở rộng mô hình MDA nhằm miêu tả chi tiết một trong những cách

mà một chuyển đổi theo vết có thể được thực hiện

Hình 2.7 Chuyển đổi mô hình theo vết

Một nền công nghệ cụ thể được lựa chọn Ánh xạ cho nền công nghệ này sẵn

có và được chuẩn bị Ánh xạ này bao gồm một bộ thiết bị đánh dấu Các dấu được

sử dụng nhằm đánh dấu các yếu tố mô hình để hướng dẫn cho quá trình biến đổi mô hình Việc sử dụng ánh xạ sẽ làm cho PIM đánh dấu được biến đổi xa hơn nhằm tạo

ra PSM [15]

 Quá trình biến đổi siêu mô hình (Metamodel)

Hình 2.8 mở rộng các mô hình MDA để diễn tả thêm chi tiết của một trong những cách mà một chuyển đổi siêu mô hình có thể được thực hiện

24

Hình 2.8 Quá trình biến đổi siêu mô hình

Mô hình được chuẩn bị bằng cách sử dụng một ngôn ngữ độc lập với nền công nghệ được xác định bởi một siêu mô hình Một nền công nghệ cụ thể được lựa chọn Đặc tả mô hình chuyển đổi nền tảng này hiện có sẵn hoặc được chuẩn bị Sự chuyển đổi đặc tả này dưới dạng ánh xạ giữa các siêu mô hình Ánh xạ chỉ dẫn sự chuyển đổi của PIM tạo ra PSM [15]

 Quá trình biến đổi mô hình

Hình 2.9 mô tả tổng quan quá trình chuyển đổi một mô hình

Hình 2.9 Quá trình biến đổi mô hình

25

Mô hình được chuẩn bị bằng cách sử dụng các kiểu độc lập nền công nghệ trong mô hình Các kiểu có thể là phần của một khung phần mềm cụ thể Các yếu tố trong PIM là các kiểu phụ của dạng độc lập nền công nghệ Một nền công nghệ cụ thể được lựa chọn Dạng biến đổi đặc tả nền công nghệ này sẵn có hoặc được chuẩn

bị sẵn Sự biến đổi này là ánh xạ giữa các kiểu độc lập nền tảng và các kiểu phụ thuộc nền tảng Các yếu tố trong PSM là kiểu phụ của các kiểu đặc tả nền tảng [15] Cách tiếp cận này khắc hẳn với ánh xạ siêu mô hình chủ yếu được thực hiện bằng các kiểu đặc tả trong một mô hình mà được sử dụng cho ánh xạ, thay thế cho các khái niệm đặc tả bởi siêu mô hình

 Quá trình biến đổi theo ứng dụng mẫu

Quá trình biến đổi theo ứng dụng mẫu là sự mở rộng các phương pháp tiếp cận ánh xạ siêu mô hình và mô hình [15] bao gồm các mẫu cùng với các kiểu hay các khái niệm ngôn ngữ mô hình kèm theo

Hình 2.10 đặc tả tổng quan của quá trình biến đổi theo ứng dụng mẫu

Hình 2.10 Quá trình biến đổi theo ứng dụng mẫu

Ngoài các kiểu độc lập nền tảng, mô hình chung có thể cung cấp các mẫu Cả hai kiểu và mẫu này có thể được ánh xạ tới các mẫu và các kiểu đặc tả nền tảng

26

Hình 2.11 chỉ ra một ví dụ tổng quát để sử dụng các mẫu: khi các tên của nền tảng cụ thể đánh dấu, có nghĩa là, tên của các mẫu thiết kế quy định cho một nền tảng

Hình 2.11 Ví dụ tổng quát về quá trình biến đổi sử dụng tên mẫu

Trong quá trình chuẩn bị mô hình PIM, ngoài việc sử dụng các tên mẫu có sẵn thì các thông tin khác có thể được thêm vào để tạo ra PIM đánh dấu mới nhằm tạo

ra PSM

2.1.2.3 Chuyển đổi mô hình trong một hệ thống phức tạp

Đối với những hệ thống phức tạp, đặc biệt là đối với các hệ thống điều khiển công nghiệp, mỗi mô hình của MDA có thể được tinh chỉnh nhiều lần trước khi chuyển sang loại mô hình khác

Ví dụ: Hình 2.12 mô tả quá trình chuyển đổi các mô hình trong một hệ thống phức tạp: mô hình CIM được tinh chỉnh nhiều lần trước khi chuyển sang mô hình PIM, mô hình PIM được tinh chỉnh nhiều lần trước khi chuyển sang mô hình PSM

và mô hình PSM cũng được tinh chỉnh nhiều lần trước khi chuyển sang code thực thi

27

Hình 2.12 Ví dụ về quy trình MDA cho một hệ thống phức tạp

2.2 Tổng quan về hệ thống điều khiển công nghiệp

2.2.1 Phân loại các hệ thống điều khiển công nghiệp

Hiện nay, các hệ thống điều khiển tự động trong công nghiệp có thể phân loại theo các loại sau: hệ thống chủ động lại, hệ thống thời gian thực và hệ thống động lực lai

2.2.1.1 Hệ thống chủ động lại

Hệ thống chủ động lại (RS: Reactive System) [9]: là hệ thống có thể nhận tất

cả sự kiện và tín hiệu đầu vào; nó xử lý các sự kiện và tín hiệu này một cách cạnh tranh có ưu tiên để đưa ra các tín hiệu và sự kiện đầu ra một cách đồng bộ

2.2.1.2 Hệ thống thời gian thực

Hệ thống thời gian thực (RTS: Real Time System) [9]: là hệ thống tự chủ động

lại có kèm theo chu trình xử lý các sự kiện và tín hiệu đầu vào, đầu ra gắn với điều kiện ràng buộc về khoảng thời gian và thời điểm thực thi Ngoài ra, trong hệ thống thời gian thực có thể phát sinh các sự kiện và tín hiệu bên trong phụ thuộc vào thời gian

2.2.1.3 Hệ thống động lực lai

Hệ thống động lực lai (HDS: Hybrid Dynamic System) [9] là hệ thống thời

gian thực; nó bao gồm phần liên tục, phần rời rạc, và sự tương tác giữa chúng

bị trong cầu thang cuốn v.v… là các hệ thống động lực lai

Trong nội dung nghiên cứu, chúng tôi quan tâm tới việc phân tích thiết kế và

mô phỏng hệ thống động lực lai công nghiệp; bởi hệ thống điều khiển hiện tại và cơ cấu chấp hành có xét tới các mô hình với dữ kiện rời rạc và mô hình ứng xử liên tục, được gọi là hệ thống động lực lai Những mô hình ứng xử này được phân tán thành các mô hình hoạt động khác nhau; chúng được kết hợp với các quá trình làm

thay đổi tác nhân với các trường hợp sử dụng (use cases) như là: người thiết kế,

người tư vấn, người bảo trì v.v…Hơn nữa, các hệ thống điều khiển luôn luôn không

có ứng xử giống nhau; do đó, nó sẽ được kết hợp với giả thuyết hợp lý để kiểm tra tại mọi thời điểm Ứng xử của các hệ thống này là khá phức tạp Trong luận văn này, chúng tôi chỉ xét đến hệ điều khiển công nghiệp đó là hệ thống động lực lai

(HDS) và được mô hình hóa bằng automate lai (Hybrid automata) [5]

2.2.2 Tổng quan về cấu trúc của HDS

Một cách tổng quát ta có thể xem hệ thống động lực lai bao gồm 3 phần [9]:

- Phần liên tục

- Phần rời rạc

- Phần tương tác giữa liên tục và rời rạc

Các thành phần này được đặc tả trong một sơ đồ trộn Tuy nhiên, các sơ đồ trộn này không cho phép nghiên cứu đối tượng điều khiển và bộ điều khiển một cách tổng hợp nó cần làm rõ một vài yếu tố về mô hình hóa về các phần tử lai

29

2.2.2.1 Phần liên tục

Để nghiên cứu phần liên tục cần phải đưa ra các kí hiệu mô hình hóa nhằm xây dựng một mô hình cho phần thực thi, các mô hình toán tổng quát Nó liên quan tới phương trình vi phân, mô hình hàm truyền đạt hoặc hệ phương trình trạng thái

2.2.2.2 Phần rời rạc

Để nghiên cứu phần rời rạc của hệ thống động lực lai, chúng ta có thể dùng các ngôn ngữ hình thức như: Grafcet, Petri Net, máy trạng thái v.v… , nhằm đặc tả ứng xử động của hệ thống Chúng ta có thể sử dụng cách tiếp cận mà nó cho phép

lập mối quan hệ giữa máy trạng thái (state machine) với mỗi tổ hợp các biến liên

tục để thực thi hệ thống Ở đây, các biến liên tục tham gia vào quá trình thực thi của các trạng thái rời rạc thông qua các điều kiện hợp lệ và dịch chuyển trạng thái dưới kiểm soát của đại lượng bất biến Ngoài ra, tổ hợp các phương trình vi phân có thể được liên kết với các trạng thái rời rạc của máy trạng thái để mô hình hóa sự thực thi ứng xử của các biến liên tục

2.2.2.3 Phần tương tác liên tục và rời rạc

Cho phép kết nối các trạng thái rời rạc của phần rời rạc với các tổ hợp biến liên tục tương ứng Sự liên kết các giá trị liên tục của hệ thống qua các trạng thái rời

rạc có thể được biểu diễn qua hàm bước nhảy (Jumps) [5], [9]

2.2.3 Hệ thống động lực lai điều khiển công nghiệp

Trong luận văn này, chúng tôi nghiên cứu sâu về phân tích thiết kế và mô phỏng hệ thống động lực lai công nghiệp Hệ thống này bao gồm phần điều khiển lai và cơ cấu chấp hành lai, hai phần này liên kết với nhau bởi sự trao đổi các tín hiệu và sự kiện theo chu kỳ và không theo chu kỳ Các sự kiện không theo chu kỳ

có thể là sự kiện bên trong hoặc bên ngoài, ta có sơ đồ khối tổng quan của hệ thống động lực lai công nghiệp như sau (Hình 2.13):

30

Hình 2.13 Sơ đồ khối tổng quan của HDS công nghiệp [9]

Trong đó:

- Evés: sự kiện đầu ra,

- Evée: sự kiện đầu vào,

- Sigs: tín hiệu đầu ra,

- Sige: tín hiệu đầu vào,

- ΔT: khoảng thời gian lấy mẫu của mô hình thực thi,

- Tác nhân1, tác nhân2, Tác nhân3… Tác nhânm: tổ hợp con người hoặc hệ thống tác động đến hệ thống thi hành (phần điều khiển lai và cơ cấu chấp hành lai)

Hệ thống thi hành và tác nhân trao đổi các thông điệp không theo chu kỳ ở dưới dạng không đồng bộ, và được thực hiện qua máy trạng thái Mặt khác, cơ cấu chấp hành lai có thể được thực thi bởi nhiều mô hình điều khiển khác nhau và tồn tại sự tương tác giữa các mô hình này, vậy sự tương tác này có thể được mô hình

hóa thông qua ngôn ngữ hình thức như: Automate, Grafcet, biểu đồ trạng thái (state chats) v.v…

2.2.4 Các điều kiện ràng buộc trong quá trình phát triển hệ thống điều khiển công nghiệp

Khi phát triển các hệ thống thống điều khiển, người ta thường xem xét tới nơi

mà ứng dụng sẽ được triển khai nhằm mục tiêu đưa ra các tiêu chí: điều kiện môi

31

trường làm việc của hệ thống, tính an toàn thiết bị và con người liên quan, chất lượng và hiệu năng làm việc của hệ thống v.v… từ đó mới quyết định đến cấu trúc tĩnh và động của hệ thống cần được thiết kế Thông thường, một hệ thống điều khiển công nghiệp được triển khai trong phòng thí nghiệm hoặc trong môi trường hoạt động thực tế; từ đó chúng ta có thể có hai khung nhìn khác nhau: khung nhìn trong thí nghiệm và khung nhìn ttrong phát triển công nghiệp nhằm mục đính đưa ra kiến trúc phát triển và các thành phần tối ưu nhất cho hệ thống này

2.2.4.1.Khung nhìn trong thí nghiệm

Chúng ta có thể đưa ra ở đây một số đặc điểm chính mà hệ thống điều khiển được phát triển trong thí nghiệm như sau:

- Hệ thống được thực thi trên một mô hình duy nhất kèm theo một thuật toán duy nhất

- Tính chắc chắn, bảo mật không phải là vấn đề quan trọng (ví dụ: hệ thống có thể bị treo hoặc quá tải mà không cần khởi động lại v.v…)

- Việc tái sử dụng các thành phần của hệ thống đã phát triển không quan trọng

- Mô hình điều khiển dễ dàng hiệu chỉnh (ví dụ: cấu trúc các bộ điều khiển, sơ

đồ khối và các tham số điều khiển v.v…)

2.2.4.2.Khung nhìn trong phát triển công nghiệp

Trên thực tế, các hệ thống điều khiển hoạt động trong môi trường triển khai thực sự, chúng ta có thể kể ra một số các ràng buộc cơ bản “các điều kiện ràng buộc

công nghiệp – Industrial Conditions” [9] như sau:

- Hệ thống phải được thực hiện bởi nhiều mô hình kèm theo nhiều thuật toán khác nhau; các mô hình này lại liên quan với nhau không tách biệt

- Mỗi mô hình đều có tính thực thi riêng rẽ theo các thuật toán cho nên tính điều khiển phức tạp

32

- Hệ thống đòi hỏi phải được bảo trì dễ dàng theo định kỳ

- Hiệu năng, độ chính xác,thời gian điều chỉnh phải được chuẩn hóa và kiểm tra tùy theo từng lĩnh vực

- Mô hình ứng dụng của hệ thống phải hoàn toàn được phát triển từ tổng quát đến cụ thể nhằm mục đích tái sử dụng các thành phần đã phát triển để thực thi các ứng dụng khác

- Con người và các hệ thống thiết bị có liên quan phải được đảm bảo an toàn

- Hệ thống điều khiển công nghiệp phải được sử dụng các chuẩn để mô hình hóa và thực thi Ngoài ra, việc phát triển hệ thống còn đòi hỏi chi phí thấp và thời gian qui định nhằm đảm bảo tiến độ của các dự án khác có liên quan tới sự vận hành của hệ thống này

2.2.5 Đặc tả Automatlai để phát triển hệ thống điều khiển công nghiệp

Một hệ Automate lai được xác định bằng hàm số sau [10]:

H = {Q, X, , A, Inv, F, q0, x0} Trong đó:

- Q: tổ hợp của các vị trí mô tả các mô hình hoạt động (chế độ hoạt động) của

hệ thống

- q0: trạng thái ban đầu

- X: không gian trạng thái liên tục hiện tại của Automate, X  n

- x0: giá trị ban đầu của trạng thái liên tục hiện tại của Automate

- : tập hợp hữu hạn của các sự kiện

- A: tập hợp các dịch chuyển được xác định bởi {q, Guard,  , Jump, q ’} và được biểu diễn bởi một cung giữa các trạng thái, trong đó:

qQ, q ’Q

Guard: một tổ hợp điều kiện cho phép thực hiện dịch chuyển

Jump: giá trị bước nhảy giữa hai không gian trạng thái liên tục của

hai vị trí liền kề nhau

33

: tổ hợp các sự kiện cho phép dịch chuyển vị trí

- Inv: đại lượng bất biến, dùng để theo dõi trạng thái liên tục phải được duy

trì; cụ thể là khi vị trí là q thì trạng thái liên tục phải được xác định theo xinv(q)

- F: hàm liên tục tổng thể (dòng liên tục) được xác định theo từng vị trí của

hệ thống; nó là tổng hợp từ các phần tử liên tục của hệ thống theo một sơ đồ điều khiển đã được xác định, tiến trình của trạng thái liên tục được xuất hiện khi trạng thái hoạt động F thường được biểu diễn bởi hệ phương trình vi phân hoặc hệ phương trình trạng thái hoặc hàm truyền đạt

Thông thường để mô hình hệ thống điều khiển, người ta sử dụng biểu đồ diễn

tiến chức năng (Functional Sequence Charts); nhưng để mô hình hóa cấu trúc và

ứng xử các HDS thì chúng ta sử dụng automate lai bởi vì:

Chỉ duy nhất một ứng xử liên tục tại một thời điểm được xác định,

Có đại lượng bất biến để kiểm tra lại giả thuyết về trạng thái liên tục

trong automate lai,

Automate lai được bắt nguồn từ automate nên mô hình ứng xử động

của hệ thống tương thích các ứng dụng tương tác sẵn có,

Nó có thể sử dụng được các công cụ phần mềm mô phỏng

Ngoài ra, để phát triển một HDS công nghiệp, chúng ta cần phải đưa ra một vài giả thiết ràng buộc với automate lai để có thể bao phủ chi tiết toàn bộ cấu trúc

và ứng xử của nó Các giả thiết này sẽ đưa nêu ở trong phần tiếp theo

Như vậy , t rong chương này chúng ta đã nghiên cứu cách tiếp cận kiến trúc hướng theo mô hình (MDA), giới thiệu về hệ thống điều khiển công nghiệp và các điều kiện trong quá trình phát triển hệ thống điều khiển công nghiệp Chúng ta cũng đưa ra một trong những loại hệ thống điều khiển công nghiệp mà chúng ta phát triển nó là hệ thống động lực lai (HDS) Trong phần tiếp theo, chúng ta sẽ đưa ra qui trình MDA cho HDS công nghiệp được mô hình hóa ứng xử (mô hình toán học) bởi automate lai

34

Chương 3- QUY TRÌNH PHÂN TÍCH VÀ THIẾT KẾ HDS CÔNG NGHIỆP

VỚI MDA

Phần này giới thiệu một phương pháp mà được dựa trên kiến trúc hướng theo

mô hình để thực thi automate lai với sự kiện, tín hiệu đầu vào và đầu ra để xác định nhanh chóng cấu trúc và sự thực thi các đối tượng điều khiển của hệ thống điều khiển công nghiệp Phương pháp này cũng cho phép các hệ thống điều khiển có thể được tái sử dụng lại trong giai đoạn thiết kế ứng dụng mới Chúng ta giới thiệu từng bước như là: phân tích kiến trúc hệ thống và các cơ chế của nó, qui trình phân tích

và thiết kế HDS theo MDA với ví dụ minh họa cụ thể Chúng ta cũng đưa ra các qui luật chuyển đổi giữa các mô hình của các đối tượng tham gia trong hệ thống phát triển

3.1 Phân tích kiến trúc hệ thống

Phân tích kiến trúc hệ thống là việc xem xét lựa chọn một cách tổ chức cấu trúc cơ bản cho việc phát triển một hệ thống dựa trên các mẫu kiến trúc Mỗi mẫu kiến trúc cung cấp một tập các gói được định nghĩa trước, chỉ rõ các nhiệm vụ của các gói đó, và bao gồm các luật và các nguyên tắc thiết lập quan hệ giữa các gói

3.1.1 Tổng quan về kiến trúc hệ thống

Trên thực tế, để tổ chức các phần tử mô hình hóa được tạo ra trong quá trình phát triển hệ thống điều khiển, chúng ta có thể sử dụng các mẫu khác nhau [4] ví dụ như là:

 Mẫu tầng : trong mẫu này một ứng dụng được phân chia thành các mức trừu tượng hóa khác nhau Các tầng giới hạn trong phạm vi từ các tầng ứng dụng cụ thể

ở trên đến các tầng thực thi hoặc nền công nghệ cụ thể ở dưới

 Mẫu MVC (Model –View – Controller) : Trong mẫu này một ứng dụng được phân chia thành 3 phần:

- Model thể hiện các luật nghiệp vụ (ứng xử nghiệp vụ) và dữ liệu cơ bản

35

- View thể hiện các thông tin được trình diễn cho người sử dụng hoặc kết nối

với các hệ thống có liên quan

- Controller được sử dụng để điều khiển xử lý thông tin đầu vào từ người sử

dụng hoặc các hệ thống có liên quan

Mỗi mẫu kiến trúc đưa ra các đặc trưng nhất định cho hệ thống cần phát triển, các đặc trưng về sự trình bày, về tiến trình xử lý và sự phân phối các thành phần trong kiến trúc Tùy vào đặc trưng của mỗi hệ thống mà người phân tích kiến trúc

có thể sử dụng một mẫu kiến trúc hoặc kết hợp nhiều mẫu kiến trúc cho hệ thống Xuất phát từ đặc điểm của MDA là đi từ mô hình ở mức trừu tượng hóa cao đến mô hình cụ thể hóa (được trình bày ở chương 2) và dựa trên đặc điểm của HDS

công nghiệp, chúng ta quyết định sử dụng mẫu tầng để phân tích, thiết kế và mô

phỏng HDS công nghiệp này

3.1.2 Xác định các tầng kiến trúc của hệ thống

Việc xác định các tầng kiến trúc của hệ thống là đưa ra cách tổ chức các phần

tử mô hình hoá trong giai đoạn phân tích thiết kế hệ thống Việc xác định các tầng kiến trúc được thực hiện theo cách nhóm các chức năng cùng loại: các chức năng cụ thể của ứng dụng được đặt ở tầng trên, các chức năng mở rộng phạm vi ứng dụng đặt ở các tầng giữa, chức năng cho môi trường triển khai đặt ở tầng dưới

Hình 3.1 trình bày một mô hình kiến trúc tầng kinh điển [4], [20] của hệ thống bao gồm 4 tầng cơ bản: tầng ứng dụng, tầng nghiệp vụ, tầng giữa và tầng phần mềm

hệ thống

36

Hình 3.1 Các tầng kiến trúc hệ thống Tầng ứng dụng: bao gồm các lớp biên, các lớp điều khiển cho hệ thống phần mềm công nghiệp đang được phát triển

Tầng nghiệp vụ: bao gồm một số các hệ thống con cụ thể có thể tái sử dụng cùng với các giao diện của chúng cho các kiểu nghiệp vụ điều khiển và các lớp thực thể

Tầng giữa: cung cấp các hệ thống con cho các tầng tiện ích và các dịch vụ độc lập với nền công nghệ thực hiện phân chia các đối tượng tính toán trong môi trường khác thể

Tầng phần mềm hệ thống: bao gồm phần mềm cho hạ tầng thực sự như các hệ điều hành, các giao diện để xác định phần cứng, các thiết bị ngoại vi v.v…

Một kiến trúc được phân tầng hợp lý sẽ thể hiện rõ các phần tử thiết kế (các lớp, các gói, các hệ thống con); các thành phần ở tầng trên chỉ sử dụng dịch vụ của các tầng dưới (không có chiều ngược lại); các thành phần không sử dụng các dịch

vụ của tầng khác nếu không có sự sử dụng dịch vụ của tầng ngay dưới nó

3.1.3 mô tả các cơ chế kiến trúc

Xác định cơ chế kiến trúc là sự quyết định về các chuẩn thực hiện chung và các nguyên tắc chung được sử dụng trong suốt quá trình phát triển phần mềm cho

hệ thống thông tin nói chung và cho hệ thống điều công nghiệp nói riêng Các cơ chế này làm giảm sự phức tạp trong quá trình phân tích, thiết kế và thực thi hệ

37

thống Cơ chế kiến trúc giúp cho các thành viên của nhóm phát triển ứng dụng sử dụng thống nhất các khái niệm, các cơ chế để thực hiện các thao tác Chúng cũng cung cấp các ứng xử cụ thể cho một lớp hoặc thành phần liên quan đến nghiệp vụ; hoặc tương ứng với sự thực thi tương đồng giữa các lớp “và/ hoặc” các thành phần

Các cơ chế kiến trúc có thể được thực thi như một khung dựng sẵn (Framework)

[4]

Ví dụ về một số cơ chế kiến trúc có thể được sử dụng trong phát triển HDS công nghiệp:

 Cơ chế phân tích: là cơ chế kiến trúc ở mức khái niệm

 Cơ chế thiết kế: là cơ chế ở mức cụ thể hơn của cơ chế phân tích Trong cơ chế này, một số các chi tiết của môi trường thực thi được giả định, nhưng không ràng buộc bởi một sự thực thi cụ thể như cơ chế thực thi

 Cơ chế thực thi: là cơ chế xác định chính xác việc thực thi cơ chế thiết kế

Cơ chế thực thi phụ thuộc vào một nền công nghệ cụ thể, ngôn ngữ cài đặt, nhà cung cấp hoặc một số nhân tố khác

Các đặc tả chi tiết của các cơ chế này có thể tham khảo trong [6]

3.1.4 Sự tham chiếu các tầng kiến trúc với MDA

Dựa vào các đặc điểm của MDA (trình bày ở chương 2) và đặc điểm của các tầng kiến trúc, cũng như tối ưu việc tổ chức các phần tử mô hình hoá, kiến trúc hướng mô hình có thể tham chiếu với các tầng kiến trúc hệ thống phát triển như sau:

- Mô hình độc lập với thao tác tính toán (CIM) bao gồm: tầng ứng dụng và một phần tầng nghiệp vụ (ví dụ: các thông tin của thực thể)

- Mô hình độc lập với nền công nghệ (PIM) bao gồm: tầng nghiệp vụ (ví dụ: thực thể, hệ thống con và các giao diện của chúng) và một phần tầng giữa (ví dụ: cơ chế truy xuất CSDL)

38

- Mô hình cụ thể của nền công nghệ (PSM) bao gồm: một phần tầng giữa (ví dụ: các cơ chế cụ thể theo nền công nghệ sử dụng NET, Java, MatLab-Simulink v.v…) và tầng phần mềm hệ thống

3.2 Đặc tả tổng quan MDA cho HDS công nghiệp

Dựa vào các đặc trưng của HDS công nghiệp (được mô tả trong chương 2) và

sự cụ thể hóa theo MDA, chúng ta áp dụng ở đây một quy trình MDA để thực thi phát triển một hệ thống điều khiển công nghiệp có ứng xử được mô tả bằng automate lai và tái sử dụng qui trình này trong ứng dụng điều khiển công nghiệp khác Hình 3.2 giới thiệu qui trình MDA tổng quan để phân tích, thiết kế và mô phỏng HDS công nghiệp

Hình 3.2 Quy trình MDA thực thi hệ thống HDS công nghiệp. 

Quy trình này được mô tả trong như sau:

Automate lai và cộng tác đối tượng với UML được đặc tả trong CIM, nó cho

39

phép phân tích cấu trúc và ứng xử của một HDS công nghiệp Theo đặc điểm của CIM, automate lai được dùng để mô tả các ứng xử toán học của hệ thống phát triển(ví dụ: vị trí – các chế độ hoạt động, biến trạng thái, dịch chuyển trạng thái, v.v…); cộng tác đối tượng với UML cho phép chuyển đổi automate đã xác định sang mô hình đối tượng nghiệp vụ của HDS

- Mô hình UML2.x và OCL (Object Contrain Language)[18] chỉ ra PIM trong

toàn bộ các giai đoạn thiết kế của hệ thống phát triển Những mô hình này được mô

tả bằng cách sử dụng các sơ đồ trong UML [2], [8]

- Mô hình MatLab-SimuLink [7] được sử dụng để đưa ra PSM của hệ thống

này để thực hiện giai đoạn mô phỏng và một phần kiểm định tích hợp hệ thống

- Luật chuyển đổi cho phép các CIM được xác định chuyển đổi thành PIM và

tiếp theo chuyển đổi các PIM vào một PSM cụ thể Trong quá trình chuyển đổi, có

tồn tại các “vết theo dõi chuyển đổi” cho phép theo dõi quá trình chuyển đổi này

giữa các mô hình

3.3 Quy trình chi tiết MDA cho HDS công nghiệp

Sau khi nghiên cứu về các đặc trưng của công nghệ hướng đối tượng, kiến trúc hướng theo mô hình kết hợp với đặc điểm của HDS được đặc tả ứng xư bởi automate lai, chúng ta đưa ra quy trình MDA nhằm để bao phủ từ phân tích thiết kế đến mô phỏng HDS này và tái sử dụng các thành phần tổng quát đã phát triển của

nó

Trong quá trình xây dựng quy trình, chúng ta lấy ví dụ và hình vẽ minh họa

được sử dụng từ một số kết phân tích “Hệ thống điều khiển cầu thang cuốn theo dõi qua camera quay” (SCCS: Sweeping Cameras Control System) nhằm làm rõ các mô hình có liên quan tới qui trình này Đặc tả hoạt động chi tiết của SCCS được trình bày trong chương 4

40

3.3.1 CIM của HDS công nghiệp

Automate lai [5] là những mô hình đặc biệt được sử dụng cách rộng rãi để mô hình hóa ứng xử của hệ thống động lực lai HDS Một HDS phối hợp với các mẫu chuyển đổi rời rạc với các ứng xử liên tục

Để mô tả một hệ thống điều khiển với automate lai, chúng tôi áp dụng các điều khiện ràng buộc sau đây:

Các sự kiện σ được xem như là sự kiện của đầu vào/đầu ra của hệ

thống

X bao gồm tính hiệu đầu vào/đầu ra

Dòng liên tục toàn cục F xuất phát từ sơ đồ khối chức năng mở rộng

Hình 3.3 đưa ra hoạt động chuyển đổi của hệ thống này với các sự kiện đến từ bên ngoài Mỗi một hộp chức năng có thể có một hoặc nhiều hơn các ứng xử liên tục được hoạt hóa bởi các sự kiện

Hình 3.3 Ví dụ về một sơ đồ chức năng mở rộng Trong đó:

E, S: tín hiệu đầu vào và đầu ra của hệ thống điều khiển phát triển, Vei, Vsi: đại lượng biến thiên vào và ra, đại lượng này sẽ tương ứng với

hộp chức năng thứ i,

Box1, Box2, Box3: Các khối chức năng của hệ thống