XÂY DỰNG SDK THEO CHUẨN OPC
Tổng quan về SDK
2.1.1 Kiến trúc chung của ứng dụng theo OPC Foudation
Hãy giả định, chúng ta đang phát triển một hệ thống gồm có server và client.
Cả server và client đều có những chức năng riêng tùy theo trường hợp được sử dụng, ví dụ như chức năng server là truy cập đến một nguồn dữ liệu (thiết bị đo, hệ quản trị cơ sở dữ liệu ) còn client là hiển thị và vẽ đồ thị cho các dữ liệu đó Tuy nhiên, chúng vẫn có những chức năng chung như quản lý kết nối, xử lý các gói tin gửi đến… Một cách tự nhiên, chúng ta cố gắng tách riêng thành những chức năng chung và những chức năng phụ thuộc vào trường hợp sử dụng Tiếp đó, những chức năng chung lại được chia ra thành những chức năng xử lý ở mức cao như quản lý kết nối, phiên làm việc, xử lý các gói tin( sau khi giải mã) và các chức năng ở mức thấp như mã hóa gói tin, bảo mật và truyền tải gói tin.
Từ đó, chúng ta có sơ đồ kiến trúc ứng dụng như sau
Hình 2.1: Sơ đồ kiến trúc ứng dụng OPC UA chuẩn [2]
Trong đó, SDK mà chúng ta định xây dựng sẽ nằm ở giữa, bên dưới tầng ứng dụng ( mà trong đồ án là ứng dụng để kiểm tra SDK và ứng dụng quan trắc môi trường) và bên trên tầng stack Tầng stack với các nhiệm vụ mã hóa, bảo mật, gửi gói tin ta có thể sử dụng lại của OPC Foundation hoặc của công nghệ WCF.
Ta có thể vẽ lại sơ đồ trên thành sơ đồ hệ thống đầy đủ gồm cả server và client
Hình 2.2:Sơ đồ hệ thống gồm server và client [12]
Như trên hình vẽ, thông tin gửi từ ứng dụng client sẽ đi qua client SDK, chuyển thành gói tin được mã hóa, bảo mật và truyền đi bởi stack ở phía client, sau đó nhận được, giải mã bởi stack phía server, rồi truyền lên ứng dụng server thông qua server SDK Phản hồi từ ứng dụng server đến ứng dụng client sẽ đi theo chiều ngược lại.
Như đã giới hạn trong phần nhiệm vụ của đồ án, tác giả sẽ tập trung phát triển các chức năng chung ở mức xử lý cao, tức là phần SDK theo định nghĩa của OPC Foudation Chức năng chung ở mức xử lý thấp (Stack) sẽ được thực hiện thông qua việc cấu hình khi sử dụng công nghệ WCF của Microsoft.
Theo như những nhiệm vụ đã đề ra ở chương 1, SDK cần có những chức năng chính sau:
Quản lý phiên làm việc, đặt timeout cho phiên làm việc
Quản lý và cho phép truy cập không gian địa chỉ.
Quản lý các đăng ký theo dõi dữ liệu (subscription).
Các chức năng hỗ trợ: Logging, bắt ngoại lệ (exception handling)… Ứng dụng client Client SDK Stack
Stack Server SDK Ứng dụng server
Kết nối Đáp ứng server của Yêu cầu client của
Chức năng theo đặc tả của OPC UA
Quản lý session Quản lý subscription
Quản lý không gian địa chỉ
Từ việc xác định chức năng, có thể vẽ sơ đồ kiến trúc tổng quan của SDK sẽ xây dựng như sau:
Hình 2.3:Kiến trúc chung của SDK 2.1.3 SDK và công nghệ WCF
WCF là công nghệ nền tảng nhằm thống nhất nhiều mô hình lập trình giao tiếp được hỗ trợ trong NET 2.0 thành một mô hình duy nhất WCF là một mô hình lập trình cho phép nhà phát triển xây dựng các giải pháp dịch vụ đảm bảo tính ổn định, bảo mật và thậm chí là đảm bảo giao dịch Nó làm đơn giản hoá việc phát triển các ứng dụng nối kết và đưa ra cho nhà phát triển những giá trị mà có thể họ chưa nhận ra ngay, đó là cách tiếp cận phát triển hệ thống phân tán thống nhất, đơn giản, và quản lý được.
Như vậy, WCF là một công cụ rất phù hợp để mô hình chuẩn OPC UA và việc xây dựng SDK dựa trên WCF tiết kiệm rất nhiều công sức cho người lập trình, giúp họ không phải can thiệp đến những xử lý ở mức thấp Ở đây, tác giả đã sử dụng stack của WCF thay vào vị trí stack trong kiến trúc của OPC UA.
Xây dựng các thành phần dùng chung giữa server và client
2.2.1 Sinh code tự động dựa trên đặc tả của OPC Foudation
UA là những đặc tả dựa trên mô hình dịch vụ web Điều đó nghĩa là tất cả những dịch vụ được định nghĩa trong UA cũng được mô tả trong một file WDSL có thể được sử dụng miễn phí bởi bất cứ ứng dụng nào hiểu về ngôn ngữ WDSL. Ngoài ra, các đặc tả của UA cũng định nghĩa những kiểu dữ liệu không được sử dụng trực tiếp bởi các dịch vụ, và do đó không được mô tả trong file WDSL đã nói ở trên Tuy nhiên, các kiểu dữ liệu này cũng được mô tả đầy đủ trong một file XML định nghĩa dữ liệu của OPC Foundation Địa chỉ của file WSDL và file định nghĩa dữ liệu được đưa ra trong phụ lục B, đặc tả số 6 trong các đặc tả của OPC Foundation.
Việc đầu tiên khi xây dựng SDK là sử dụng công cụ sinh code tự động svcutil.exe của WCF để sinh ra giao diện của dịch vụ, và các lớp tương ứng với các kiểu dữ liệu được mô tả trong đặc tả.
Sinh ra giao diện dịch vụ và các kiểu dữ liệu vào ra dịch vụ svcutil
/namespace:*,Opc.Ua http://opcfoundation.org/UA/2008/02/Services.wsdl /out:Opc.Ua.Services.cs /reference:C:\windows\Microsoft.NET\Framework\v2.0.50727\System.dll
/ct:System.Collections.Generic.List
Sinh ra các kiểu dữ liệu không dùng trực tiếp bởi dịch vụ svcutil /dconly /namespace:*,Opc.Ua Types.xsd /out:Opc.Ua.Types.cs
Sau khi sử dụng công cụ sinh code tự động, thu được 2 file Opc.Ua.Services.cs và Opc.Ua.Types.cs với hơn 21000 dòng lệnh.
2.2.2 Sử dụng một số hỗ trợ được cung cấp bởi OPC Foundation
Ngoài các file định nghĩa dữ liệu và dịch vụ ở trên, OPC Foundation còn cung cấp trực tiếp các file chứa giá trị chuẩn như đã được mô tả trong đặc tả Các giá trị chuẩn đó là id của các node, status code, thuộc tính, các kiểu liệt kê ….
Những hỗ trợ này có thể được lấy về trực tiếp từ trang web của OPC Foundation.
2.2.3 Mở rộng các kiểu dữ liệu được sinh ra bởi công cụ sinh code
Bởi các kiểu dữ liệu sinh ra bởi công cụ thường rất đơn giản, chỉ chứa các thuộc tính và hàm khởi tạo mặc định, không đáp ứng được các đặc tả chặt chẽ của UA nên ta cần bổ sung thêm các phương thức hỗ trợ Tuy nhiên do có quá nhiều kiểu dữ liệu, nên tác giả chỉ lựa chọn một số kiểu dữ liệu để viết phần mở rộng, đó là :NodeId, ExpandedNodeId, ExtensionObject, Variant, DataValue, StatusCode,
Mở rộng để hỗ trợ kiểu NodeId là kiểu số nguyên.
Hình 2.4: Lớp NodeId 2.2.3.2 ExpandedNodeId
Thực hiện tương tự như NodeId:
Thực chất ExpandedNodeId chưa có sự mở rộng (expand) so với NodeId như yêu cầu cầu của đặc tả Nhưng điều này chưa quan trọng vì ExpandedNodeId là để làm việc giữa các không gian địa chỉ khác nhau và trong quá trình demo không có sự dùng chung không gian địa chỉ giữa các server khác nhau mà chỉ có một server duy nhất hoạt động.
2.2.3.3 ExtensionObject Đây là kiểu dữ liệu mà theo đặc tả thì “có khả năng lưu trữ bất kỳ giá trị nào mà không thể chuyển về một trong các kiểu giá trị cơ bản”
2.2.3.4 Variant Đây là kiểu dữ liệu cho phép lưu trữ các giá trị cơ bản trong hệ thống
2.2.3.5 DataValue Đây là kiểu dữ liệu lưu giá trị mà server trả lại cho client
Hình 2.8: Lớp DataValue 2.2.3.6 StatusCode Đây là kiểu dữ liệu lưu trữ trạng thái dịch vụ Trạng thái có thể từ kết quả của dịch vụ cho đến kết quả một bước nhỏ trong xử lý.
Xây dựng Server SDK
2.3.1 Kiến trúc chung của server
Nhắc lại về các chức năng của server, server trong đồ án phải có các chức năng sau:
Tạo ra các điểm cuối cho phép client kết nối và sử dụng các chứng nhận trong kết nối
Quản lý các phiên làm việc của client
Quản lý các đăng ký theo dõi thông tin nút (subscription)
Quản lý nút và thuộc tính
Kiến trúc tổng quan của server trong SDK có thể được mô tả trong hình 18. Trong đó có thành phần là :
ServerBase : Là lớp cao nhất trong ứng dụng, mô hình hóa hoạt động của cả ứng dụng server Lớp được xây dựng bằng cách thực thi 2 giao diện sinh ra từ đặc tả của UA là ISessionEndpoint và IDiscoveryEndpoint Đây là lớp trừu tượng, người viết ứng dụng server cần kế thừa từ lớp này.
Server sẽ thực sự khởi động sau khi gọi phương thức Start(), phương thức này sẽ tạo ra các điểm cuối của dịch vụ để client có thể kết nối.
Hình 2.10: Kiến trúc chung của server SDK IServerInternalData : Đây là 1 giao diện, một lớp thực thi giao diện này sẽ được sử dụng để bao hàm những thành phần có thể được gọi đến bởi những thành
NodeManger, SubscriptionManager cần kiểm tra 1 session quản lý bởi SessionManager Giao diện này bao gồm các lớp như trên hình vẽ đã mô tả : SessionManager, INodeManger, SubscriptionManager, ApplicationDescription, EndpointDescription, ISercurityHelper
ServiceHost : Đối tượng nằm trong gói thư viện NET của Microsoft, dùng để tạo các điểm cuối cho dịch vụ.
MasterNodeManager và INodeManager : thực thi tất cả các dịch vụ liên đến việc truy cập đến không gian địa chỉ MasterNodeManager bao gồm 1 CoreNodeManager và có thể là nhiều đối tượng với giao diện INodeManager khác.
CoreNodeManager: Thực thi giao diện INodeManager Khi đối tượng
CoreNodeManager được khởi tạo, nó load toàn bộ không gian địa chỉ tiêu chuẩn từ file vào bộ nhớ Đây là những nút có id được định nghĩa trước, và có thể sử dụng thuận tiện trong lập trình.
SessionManager : thực thi những dịch vụ liên quan đến quản lý session như
CreateSession, ActivateSession, CloseSession Lớp này cũng duy trì một đếm thời gian để xác định những phiên làm việc nào đã bị quá hạn.
Session: là thực thể lưu thông tin về một phiên làm việc Nó cung cấp hàm
Activate cho phép khả năng kích hoạt chính nó dựa trên tham số truyền vào là được chấp nhận.
SubscriptionManager: có nhiệm vụ quản lý các đăng ký thu thập thông tin
(subscription) và phần tử được theo dõi (monitored item) Đối tượng này định kỳ thu thập thông tin từ các giá trị và lưu thay đổi vào các phần tử tương ứng Đồng thời định kỳ tổng hợp các thay đổi đó thành các bản tin vào các đăng ký để đáp ứng các yêu cầu xuất ra bản tin từ client
SessionPublishQueue: một phiên làm việc có thể có nhiều subscription, và có một hàng đợi các yêu cầu (request) Đối tượng này được buộc vào một phiên làm việc, hỗ trợ SubscriptionManager chọn ra Subscription thích hợp để trả lại các bản tin thông báo(Notification Message), đồng thời lưu các yêu cầu gửi đến vào một hàng đợi để xử lý dần.
Subscription: đối tượng này bao gồm nhiều phần tử cần theo dõi và nó sẽ chuẩn bị những bản tin thông báo để đáp lại những yêu cầu của client đang ở trong hàng đợi.
MonitoredItem: chứa những thông tin cần theo dõi trong đó có id của nút, id của thuộc tính Đối tượng này được SubscriptionManager định kỳ đẩy dữ liệu vào, và sau đó lại được Subscription lấy ra để tạo nên bản tin thông báo.
2.3.2.1 Kết nối và mô hình điểm cuối dịch vụ
Trong đồ án, SDK được xây dựng dựa trên công nghệ WCF, là một phần của thư viện NET kể từ phiên bản 3.0 Tất cả các kết nối giữa client và server trong WCF thông qua các điểm cuối Mô hình điểm cuối của WCF có thể được hiểu qua hình vẽ sau:
Hình 2.11: Điểm cuối trong WCF
Bất kỳ dịch vụ nào phải có 1 địa chỉ (address) chỉ ra dịch vụ ở đâu, một bản ràng buộc (binding) định nghĩa cách để kết nối với dịch vụ và một hiệp nghị (contract) mô tả những việc mà service có thể thực hiện Một điểm cuối của dịch vụ có thể coi như là hợp lại của 3 yếu tố này: địa chỉ, ràng buộc, hiệp nghị Một cách dễ nhớ, có thể gọi đây là mô hình ABC (address,binding,contract) của dịch vụ.Mọi dịch vụ đều phải có ít nhất 1 điểm cuối và mỗi điểm cuối chỉ thuộc về duy nhất một dịch vụ Những điểm cuối này được tạo ra khi server bắt đầu làm việc.Một ứng dụng client muốn kết nối với server thông qua điểm cuối dịch vụ phải tạo một kênh dữ liệu (channel) có khả năng truyền đi các thông điệp (message) Sử dụng WCF, ta có thể lấy được Id cũng như các thông tin của kênh dữ liệu này cho các ứng dụng ở tầng cao hơn.
UA có định nghĩa lại về kết nối giữa client và server như trong hình vẽ sau.
Hình 2.12: Kết nối giữa UA client và UA server [2]
Kết nối theo định nghĩa của UA bao gồm:
Tầng vận chuyển (tranport layer) có thể sử dụng các chuẩn quốc tế như TCP, HTTP.
Kênh dữ liệu an toàn (secure channel)
Phiên làm việc (Session) dùng để xác thực người dùng theo cách riêng của từng ứng dụng client hay server.
Như vậy, ra thấy có sự tương ứng giữa mô hình của UA và mô hình WCF mà trong đó WCF linh hoạt hơn khi không định nghĩa trực tiếp phiên làm việc Từ đó, tác giả đã quyết định cấu hình để kênh dữ liệu của WCF giống với UA và xây dựng tầng quản lý phiên làm việc dựa trên kênh dữ liệu mà WCF tạo ra nhằm biến kết nối của WCF thành kết nối theo đúng đặc tả của UA.
2.3.2.2 Xây dựng điểm cuối dịch vụ
Trong việc chuyển đối kênh dữ liệu về đặc tả UA thì việc mã hóa, giải mã của
UA là rất phức tạp, ở phạm vi đồ án tác giả đã quyết định sử dụng cách mã hóa chuẩn theo WCF chứ chưa xây dựng lại theo đúng với UA Ở đây, tác giả chỉ đề xuất một cách để có thể biến đổi kênh dữ liệu về đúng với UA, với mục đích lớn nhất có thể là giúp cho SDK tự xây dựng này có thể giao tiếp với các UA SDK khác.
Như đã giới thiệu ở trên, một điểm cuối dịch vụ bao gồm 3 yếu tố: địa chỉ, ràng buộc và hiệp nghị Trong đó, địa chỉ chỉ là một uri định nghĩa dịch vụ ở đâu, điều này phụ thuộc vào ứng dụng cụ thể, còn hiệp nghị mô tả những việc dịch vụ có thể làm, cũng đã được quy định rõ ràng trong file mô tả dịch vụ WDSL mà ta dùng để sinh code tự động Chỉ có các ràng buộc (binding) là ta có thể tùy biến để thay đổi cách kết nối giữa client và server Để định nghĩa một ràng buộc tùy biến (custom binding) ta cần xây dựng một lớp mới kế thừa từ lớp System.ServiceModel.Channels.Binding trong thư thể xây dựng được những đối tượng Binding tương ứng với cấu hình của ứng dụng.
Xây dựng Client SDK
Trong SDK thì phần server được xây dựng chi tiết, còn phía client thì chủ yếu được xây dựng với mục đích sử dụng được những dịch vụ trên server Kiến trúc phía client thể hiện như trong hình vẽ: act PublishTimerExpired
Check if publish timer expired
Check if manager is still running has message to publish
Demo kiểm tra chức năng của SDK
Trong đó, thì client gọi đến các dịch vụ của server được là nhờ 2 đối tượng SessionClientEndpoint và DiscoveryClientEndpoint, đấy thực chất là 2 đối tượng sinh ra nhờ công cụ sinh code Ngoài ra client còn được hỗ trợ bởi đối tượng BindingFactory và một đối tượng kế thừa từ ISercurityHelper Trong đó BindingFactory giúp client xây dựng những cấu hình đúng để kết nối đến server còn ISecurityHelper để xác thực thông tin của server.
Hiện tại client còn đơn giản do tác giả không đủ thời gian xây dựng đầy đủ chức năng cho client nhưng tác giả cũng xin đề xuất thêm các chức năng mới cần có ở client như sau:
Có khả năng gửi liên tục các yêu cầu lấy bản tin thông báo mà không cần người sử dụng SDK phải can thiệp nữa.
Giữ thông tin của các đăng ký và các phần tử theo dõi dữ liệu, và có khả năng kiểm tra lại các thông tin trên server.
Nhỡ sẵn một phần không gian nút để tiết kiệm việc gửi các yêu cầu.
Tự động duy trì phiên làm việc và các đăng ký trong phiên làm việc.
Về client SDK, chi tiết cách sử dụng sẽ được nói ở phần ứng dụng kiểm tra SDK.2.5 Demo kiểm tra chức năng của SDK
TestServer là 1 server demo đơn giản được xây dựng trên SDK để tận dụng những xử lý có sẵn trong SDK Các bước xây dựng TestServer gồm có:
Tạo ra một lớp kế thừa từ SercurityHelper Điều này có nghĩa là ta cần thực thi 3 phương thức của giao diện như sau: public override X509Certificate2 InitializeCertificate(){……} public override bool Validate(X509Certificate2 certificate) {……} public override uint Validate(ExtensionObject userIdentityToken) {……} class Client Arch
Kế thừa từ lớp ServerBase
Ta cần ghi đè 2 lên 2 phương thức trừu tượng : protected override SecurityHelperBase CreateSecurityHelper(){……} protected override IServerInternalData IntinializeInternalData(){……}
Trong đó thì hàm CreateSercurityHelper phải trả lại đối tượng kế thừa từ lớp SercurityHelperBase mà ta đã xây dựng trước đó Điều quan trọng nhất trong việc kế thừa từ lớp Server là ghi đè hàm IntinializeInternalData Trong hàm này, ta phải cung cấp đầy đủ thông tin mô tả điểm cuối của dịch vụ.
Kết quả là một ứng dụng Console như hình dưới:
Hình 2.33: Ứng dụng TestServer 2.5.2 TestClient
Xây dựng TestClient phức tạp hơn ứng dụng TestServer ở chỗ có cả giao diện GUI Hai bước đầu tiên để xây dựng TestClient cũng giống như với TestServer:
Tạo ra một lớp kế thừa từ SercurityHelper Điều này có nghĩa là ta cần thực thi 3 phương thức của giao diện như sau: public override X509Certificate2 InitializeCertificate(){……} public override bool Validate(X509Certificate2 certificate) {……} public override uint Validate(ExtensionObject userIdentityToken) {……}
Kế thừa từ lớp ClientBase
Ta cần ghi đè 2 lên 2 phương thức trừu tượng : protected override SecurityHelperBase CreateSecurityHelper(){……} protected override ApplicationDescription InitializeClientInfo(){……}
Giao diện của Client thể hiện trong hình vẽ dưới đây:
Hình 2.34:Giao diện TestClient
Sau đây, ta sẽ phân tích kỹ hơn về từng chức năng của client:
Hiển thị các nút dưới dạng cây: Tuy các nút trong OPC UA có rất nhiều tham chiếu đến nhau, nhưng để dễ quan sát, ta hiển thị các nút theo các quan hệ là con của kiểu HeararchicalReference, xuất phát từ nút nút Root.
Hình 20:TestClient – chức năng hiển thị treeview Để duyệt các nút, ta gọi đến dịch vụ Browse, giá trị các tham số truyền vào như sau:
Bảng 7: Giá trị các tham số cho dịch vụ Browse ở TestClient
Tên Giá trị Giải thích
BrowseDirection Forward Chiều để duyệt Có thể là :
Forwart, Inverse hoặc Both. ReferenceTypeId NodeId ứng với kiểu
NodeClassMask 0 Tạm thời bỏ qua
ResultMask 63 Tất cả các thuộc tính.
Vẽ đầy đủ quan hệ của nút với các nút khác: Tuy hiển thị dưới dạng treeview đã tương đối dễ theo dõi, nhưng lại không hiển thị đầy đủ các tham chiếu từ một nút Vẽ đầy đủ các quan hệ là một cách tốt để kiểm tra không gian nút.
Hình 2.35:Testclient – chức năng hiển thị sơ đồ
Ta sử dụng dịch vụ Browse tương tự như trên, chỉ khác ở tham số ReferenceTypeId, phải ứng với kiểu References, là kiểu gốc của tất cả các loại tham chiếu
Hiển thị giá trị các thuộc tính khi người dùng click vào một nút trên treeview
Hình 2.36:TestClient - chức năng xem thuộc tính Để thực hiện chức năng này, ta dùng dịch vụ Read, các tham số truyền vào như sau
Bảng 8:Giá trị các tham số cho dịch vụ Read ở TestClient
Tên Giá trị Giải thích
NodeId Mã của nút cần duyệt
AttributeId Lần lượt id của các attribute ứng với NodeClass được truyền vào
IndexRange Bỏ qua Không đọc giá trị dạng mảng
Khi người dùng ấn chuột phải vào nút và chọn “Monitor value” thì giá trị của nút sẽ được client theo dõi trong 1 listview.
Hình 2.37:TestClient- chức năng theo dõi giá trị thay đổi Để thực hiện chức năng này, trước hết phải tạo 1 bản đăng ký nhờ dịch vụ CreatSubscription, sau đó, khi client chọn “Monitor value” thì sẽ thêm phần tử cần theo dõi vào bản đăng ký của client nhờ dịch vụCreateMonitoredItem Để thông tin được cập nhật liên tục thì client phải gọi liên tục dịch vụ Publish.
Ứng dụng quan trắc môi trường
Vai trò của OPC UA đối với hệ thống
Tóm tắt các nhiệm vụ đề ra trong đồ án tốt nghiệp
Nghiên cứu lý thuyết OPC UA.
Xây dựng SDK theo chuẩn OPC UA và viết ứng dụng kiểm tra chức năng của SDK
Áp dụng SDK để xây dựng ứng dụng hệ thống quan trắc môi trường.
Môi trường thực hiện đồ án tốt nghiệp: Bộ môn Công nghệ phần mềm, Viện
CNTT & Truyền thông – Đại học Bách Khoa Hà Nội.
Bố cục đồ án: Bao gồm phần mở đầu, nội dung chính và kết luận
Phần mở đầu: Giới thiệu tóm tắt nhiệm vụ đề tài, xác định mục tiêu và phạm vi thực hiện.
Phần nội dung: Kết cấu 3 chương
Chương 1- Đặt vấn đề và định hướng giải pháp: Giới thiệu tổng quan về OPC
UA, lý do và định hướng ban đầu cho việc xây dựng SDK theo OPC UA, mô tả sơ lược về hệ thống quan trắc môi trường.
Chương 2 – Xây dựng SDK theo OPC UA: Trình bày các phân tích và thiết kế để ánh xạ từ đặc tả chuẩn vào một SDK cụ thể
Chương 3 – Hệ thống quản lý thông tin môi trường: Trình bày tổng quan về khả năng ứng dụng và kiến trúc của hệ thống, mô tả cách sử dụng SDK vào xây dựng hệ thống.
Kết luận: Đánh giá về kết quả thực hiện đồ án, phân tích những thuận lợi, khó khăn khi thực hiện đồ án, định hướng phát triển đồ án trong tương lai.
CHƯƠNG 1: ĐẶT VẤN ĐỀ VÀ ĐỊNH HƯỚNG GIẢI PHÁP
Nội của chương này sẽ trình bày các vấn đề sau: o Giới thiệu chung về OPC UA o Bài toán xây dựng OPC UA SDK: mô tả và định hướng giải quyết o Ứng dụng quản lý thông tin môi trường: ý tưởng, sơ đồ hệ thống
1.1 Giới thiệu chung về OPC UA
OPC là chuẩn giao tiếp giữa server và client được sử dụng trong tự động hóa công nghiệp và trong các hệ thống xí nghiệp nhằm hỗ trợ điều khiển và giám sát thiết bị Được đưa ra năm 1996, chuẩn OPC đã đạt được những thành công nhanh chóng cũng như những cam kết hỗ trợ từ nhiều tập đoàn lớn Tuy nhiên, cùng với sự phát triển của công nghệ dịch vụ web, và yêu cầu có thể giao tiếp giữa các ứng dụng chạy trên các nền tảng khác nhau, OPC dần trở nên lạc hậu Năm 2006, OPC Foundation, tổ chức duy trì và phát triển chuẩn OPC, đã đưa ra một chuẩn mới OPC
UA , đây không chỉ là sự nâng cấp từ chuẩn cũ, mà còn là một giải pháp toàn diện, một framework hỗ trợ xây dựng những mô hình thông tin phức tạp, tạo những kết nối an toàn nhằm truy xuất dữ liệu thời gian thực, dữ liệu trong quá khứ cũng như điều khiển thiết bị.
1.1.2 Vai trò của OPC UA trong hệ thống
Vai trò của OPC UA trong hệ thống tương tự như vai trò của hệ điều hành Windows trong việc điều khiển máy in Trước kia, mỗi hãng sản xuất máy in khi đưa ra một loại máy in mới đều kèm theo một trình điều khiển để phần mềm có thể sử dụng máy in Điều đó dẫn tới khả năng phần mềm sử dụng được một máy in phụ thuộc vào việc người viết phần mềm có trong tay trình điều khiển của máy in đó hay không, nói cách khác, những phần mềm cũ không thể sử dụng được các máy in đời mới Điều này chỉ thay đổi khi hệ điều hành Windows của Microsoft đứng ở giữa, đảm nhiệm việc giao tiếp với máy in, và khi đó, người viết phần mềm chỉ cần quan tâm đến việc sử dụng giao diện điều khiển máy in mà Microsoft cung cấp Sự thay đổi này đã tiết kiệm rất nhiều chi phí cho việc phát triển phần mềm.
Hình 1.1: Ví dụ về trình điều khiển máy in
Cũng tương tự như vậy, trước khi chuẩn OPC ra đời, mỗi hãng sản xuất đưa ra các thiết bị với những giao diện sử dụng rất khác nhau, và việc làm thế nào để truyền dữ liệu giữa các thiết bị của các hãng khác nhau đôi khi đòi hỏi người phát triển phải mất nhiều thời gian để xây dựng riêng phần giao tiếp với từng thiết bị. Trong khi đó, công nghệ mà các hãng sử dụng thường không có quá nhiều khác biệt Bởi vậy, chuẩn OPC đã được phát triển, đưa vào ứng dụng và trở thành một
“ngôn ngữ” chung giữa các thiết bị cùng với phần mềm.
Hình 1.2: Vai trò của chuẩn OPC [15]
Như hình vẽ trên, OPC đã đứng ở giữa, thay các ứng dụng quản lý dữ liệu, các ứng dụng giao diện người dùng (HMI) , các hệ thống điều khiển để giao tiếp với thiết bị.
OPC từ lúc ra đời (1996) đến nay đã thu được rất nhiều thành công, và vẫn đang được tiếp tục sử dụng, nhưng vẫn có những mặt hạn chế Có thể kể ra như: sự phụ thuộc và COM/DCOM, những công nghệ đã tương đối lạc hậu của Microsoft; chỉ có thể sử dụng trên nền Microsoft Windows; đưa ra quá nhiều đặc tả riêng cho từng loại dữ liệu: DA(Data Access), HA(Historical Access), A&E(Alarm & Event
…) Vì thế, OPC Foundation đã đưa ra một chuẩn mới: OPC UA Và đó chính là chuẩn mà tác giả sẽ nghiên cứu trong đồ án tốt nghiệp này.
1.1.3 Các đặc tả của OPC UA
Các đặc tả OPC UA được phân chia thành các phần khác theo như chuẩn hóa IEC OPC UA được biết đến như là tiêu chuẩn IEC 62541 Hình ảnh sau đây thể hiện tổng quan các đặc tả, chia thành: Các đặc tả cốt lõi định ra cơ sở cho OPC UA và các đặc tả về truy cập.
Hình 1.3 : Các đặc tả của OPC Foundation [15]
Phần 1: Khái niệm (Concepts) đưa ra những khái niệm và giới thiệu tổng quan về OPC UA
Phần 2: Mô hình bảo mật (Security Model) mô tả mô hình để bảo đảm cho việc truyền tin giữa server và client
Phần 3: Không gian địa chỉ (Address Space) mô tả nội dung bên trong và cấu trúc mô hình thông tin trên server
Phần 4: Dịch vụ (Services) chỉ rõ các dịch vụ cung cấp bởi server
Phần 5: Mô hình thông tin (Information Model) định nghĩa các kiểu, các đối tượng và quan hệ giữa chúng trên server
Phần 6: Ánh xạ (Mapping) chỉ rõ việc chuyển đổi từ đặc tả của OPC UA về thực thi ở tầng vận chuyển và mã hóa dữ liệu.
Phần 7: Các hồ sơ (Profiles) đưa ra các mẫu có thể được hỗ trợ bởi server và client Mỗi hồ sơ là một nhóm các chức năng.
Phần 8: Truy nhập dữ liệu (Data Access) hướng dẫn người phát triển ứng dụng cách để truy cập dữ liệu trên server.
Phần 9: Cảnh báo và điều kiện (Alarms and Conditions) chỉ rõ những hỗ trợ của server để phục vụ cho chức năng này.
Phần 10: Chương trình (Programs) mô tả những nguyên lý tiêu chuẩn để mô hình hóa một chương trình chạy vào không gian địa chỉ trên server.
Phần 11: Truy nhập dữ liệu lịch sử (Historical Access) chỉ cách để người phát triển ứng dụng truy cập dữ liệu và sự kiện lịch sử trong server
Phần 12: Khám phá (Discovery) mô tả cách server khám phá (discovery server) vận hành và tương tác với server và với client.
1.1.4 Những lợi ích của việc sử dụng OPC UA
Cách truy cập dữ liệu duy nhất đối với dữ liệu thời gian thực, dữ liệu quá khứ và sự kiện: Trong OPC UA, không có sự phân biệt giữa các loại thông tin kể trên, tất cả đều được mô tả dưới dạng nút trong không gian địa chỉ.
Hình 1.4: UA thay thế DA, AE và HAD [15]
Sự đảm bảo và đáng tinh cậy nhờ thành công của chuẩn OPC trong quá khứ.
Hình 1.5: OPC UA - sự đảm bảo về chất lượng [15]
Khả năng truy cập đến dữ liệu vượt qua tường lửa và qua mạng internet nhờ sử dụng chuẩn Web Service:
Hình 1.6: Vượt qua internet và tưởng lửa [15]
Tạo ra sự thống nhất chung giữa các hãng phần cứng nhờ một mô hình thông tin (information model) duy nhất Như hình vẽ dưới đây, bất kì thiết bị nào cũng bao gồm những thông tin chung như serial, tên hãng, và đó là cơ sở đễ viết những ứng dụng với giao diện thiết bị chung cho tất cả các hãng
Hình 1.7: Ví dụ về mô hình thông tin chung [15]
Thống nhất mô mô hình bảo mật dữ liệu duy nhất giữa các hãng thông qua cơ chế chuẩn certificate (giấy chứng thực)
Hình 1.8: UA và giấy chứng thực [15]
Một giải pháp có thể sử dụng ngay trên những phần mềm nhúng, cho đến những hệ thống quản lý doanh nghiệp.
Hình 1.9: Từ phần mềm nhúng đến hệ thống [15]
Độc lập với các nền tảng khác nhau như Windows, Linux, Mac
Hình 1.10: Mac, Windows hay Linux [15]
Có nhiều lựa chọn cho việc truyền các bản tin: mã nhị phân cho các ứng dụng đòi hỏi cao về hiệu suất, và xml cho những hệ thống quản lý:
Hình 1.11: SOAP/XML hay UA Binary [15]
Tuy phức tạp, nhưng OPC UA có thể đóng gói tất cả trong SDK, và điều đó tiết kiệm rất nhiều chi phí phát triển.
Hình 1.12: UA SDK - giải pháp tiết kiệm chi phí [15]
1.2 Bài toán xây dựng SDK theo OPC UA
1.2.1 Lý do đưa ra bài toán
OPC UA đã được đưa vào sử dụng, và được chứng minh tính thực tế và hiệu quả của nó nhưng ở Việt Nam, những ứng dụng và cả những nghiên cứu về OPC
UA là rất hạn chế, thậm chí chưa có công ty nào công bố kết quả nghiên cứu, và viện CTTT và truyền thông cũng mới chỉ bắt đầu nghiên cứu từ năm 2010 Đây cũng là một khó khăn cho tác giả, vì những kết quả có thể kế thừa là rất ít Mặt khác, những đặc tả của tổ chức OPC Foundation về chuẩn OPC UA là rất mềm dẻo, và không phụ thuộc vào nền tảng nào cả, nên cũng rất trừu tượng và khó nắm bắt. Còn những SDK đã được viết theo chuẩn OPC UA, thì hoặc là rất đắt, không phục vụ cho mục đích nghiên cứu (Prosys, UA SDK), hoặc là không đầy đủ chức năng (bản free của Unified Automation), và đều có điểm chung là đóng kín đối với người phát triển ứng dụng Vì thế, sau giai đoạn định hướng cho đề tài tốt nghiệp, tác giả đã đề ra nhiệm vụ cho đồ án tốt nghiệp là : Tự xây dựng một SDK theo những đặc tả của OPC Foundation và viết ứng dụng để minh họa những chức năng đã được hỗ trợ trong SDK, từ đó, sử dụng SDK trong ứng dụng quan trắc môi trường để lấy ứng dụng này chứng minh cho tính thực tế và hiệu quả của chuẩn OPC UA.
1.2.2.1 Kiến trúc chung của một hệ thống sử dụng OPC UA
Kiến trúc chung được mô tả qua hình vẽ:
Hình 1.13: Kiến trúc của một hệ thống OPC UA [1]
Kiến trúc của 1 ứng dụng server hay client đều bao gồm
Tầng ứng dụng : thay đổi tùy theo yêu cầu của ứng dụng
SDK : thư viện bao gồm các mô đun quản lý nodes, session, event….
Stack : Chịu trách nhiệm mã hóa, bảo mật và gửi các gói tin đi.
1.2.2.2 Các yêu cầu cụ thể trong phạm vi đồ án
Giới thiệu hệ thống về phần cứng
Các cảm biến được thiết kế và lắp đặt nhờ các thành viên khác trong nhóm nghiên cứu, tác giả không trực tiếp tham gia nên chỉ giới thiệu các cảm biến như dưới đây:
Cảm biến pH (Hana, HI1230) là một trong những loại cảm biến đang được dùng phổ biến hiện nay, cảm biến có chức năng chuyển đổi giá trị pH trong dung dịch thành giá trị điện áp tương ứng, điện áp đầu ra của cảm biến có dải từ -414mV đến +414mV (ở 25 0 C).
Cảm biến DO (Hana, HI76409) là điện cực được dùng để đo nồng độ oxy hòa tan trong nước theo phương pháp Galvanic.
Cảm biến độ dẫn là hai bản cực kim loại (thép không rỉ) đặt đối diện nhau
Cảm biến ánh sáng được dùng là IC photodiode (OPT101) dùng để đo cường độ sáng tại khu vực kiểm tra với tín hiệu đầu ra là điện áp tỷ lệ với cường độ sáng thu được.
Độ đục không đo trực tiếp nồng độ các hạt lơ lửng trong nước mà là đo sự phân tán ánh sáng gây ra bởi các hạt đó Cảm biến đo độ đục được chế tạo dựa trên cảm biến ánh sáng.
Cảm biến đo độ sâu sử dụng phương pháp đo gián tiếp thông qua sử dụng cảm biến áp suất do áp suất của một khối nước gây ra tỷ lệ với độ sâu của khối nước đó Loại cảm biến áp suất được dùng là MPXV7035 có đầu ra là điện áp trong dải từ 0.2 đến 4.7V.
Cảm biến nhiệt độ được sử dụng là LM35, đây là loại cảm biến thông dụng dùng để đo nhiệt độ Có điện áp ra tỷ lệ với nhiệt độ của môi trường.
3.3.2 Vi điều khiển và sim
Vi điều khiển được chọn là ATmega128 do có những tính năng vượt trội như:
8 kênh ADC với độ phân giải 10bit, 2 khối USART lập trình được, 64 thanh ghi I/O, tần số hoạt động tối đa là 16MHz… đáp ứng đủ những yêu cầu về cấu hình cho hệ thống.
SIM được sử dụng là SIM548C, loại SIM này là một Module GSM/GPRS và GPS, có thể làm việc trên cả 4 băng tần EGSM 900Mhz/DCS 1800Mhz và GSM 850Mhz/PCS 1900Mhz Ngoài ra SIM còn hỗ trợ công nghệ định vị toàn cầu GPS.
3.3.3 Mạch thiết kế rút gọn của hệ thống Được gửi trong tài liệu kèm theo của đồ án.
Phân tích và thiết kế phần mềm
3.4.1 Phân tích hệ thống về chức năng
Nhiệm vụ của phần mềm là thu thập số liệu được gửi từ các trạm tại sông, hồ ở các địa phương khác nhau thông qua GPRS và giao thức TCP/IP, lưu giữ số liệu đó vào cơ sở dữ liệu tại trung tâm Mỗi số liệu được đánh mã, kèm theo mã thiết bị gửi, thời gian gửi, v.v… Dựa trên cơ sở dữ liệu này, người quản lý sẽ xây dựng được các thống kê về thực trạng môi trường nước sông hồ tại địa phương, từ đó đưa ra đánh giá chính xác và có các biện pháp xử lý kịp thời.
Bảng 9: Chức năng của server quan trắc
Mã số Tên Mô tả chi tiết
F01S Thu nhận và lưu trữ số liệu từ thiết bị đo
Lắng nghe nếu có dữ liệu thiết bị gửi về. Tần suất: Thời gian thực.
Lưu vào CSDL với các thông số sau:
Thời gian gửi bản tin.
Các thông số đo được.
F02S Dịch vụ truy vấn dữ liệu thời gian thực Lắng nghe yêu cầu từ client, truy vấn dữ liệu để vẽ đồ thị thông số thời gian thực
F03S Dịch vụ truy vấn báo cáo Lắng nghe yêu cầu từ client, xây dựng báo cáo về thông số theo yêu cầu.
F04S Cảnh báo khi thông số vượt ngưỡng
Phát hiện khi dữ liệu thông số môi trường có dấu hiệu bất thường hay có thay đổi đột ngột. Đưa ra cảnh báo.
Mã số Tên Mô tả chi tiết
F05C Truy vấn thông tin thiết bị
Lấy thông tin thiết bị, bao gồm:
Phân loại, sắp xếp thiết bị theo tên hoặc vị trí địa lý.
F06C Truy vấn dữ liệu thời gian thực
Cho phép vẽ đồ thị thông số của thiết bị theo thời gian thực bằng cách cập nhật liên tục dữ liệu của thiết bị đó từ server trung tâm.
F07C Hiển thị cảnh báo Khi có thông tin cảnh báo vượt ngưỡng, hiển thị trên màn hình để người quan lý xử lý kịp thời.
Truy vấn báo cáo theo yêu cầu của người quản lý.
Xuất nội dung báo cáo.
3.4.2 Thiết kế cơ sở dữ liệu
Hệ thống được xây dựng trong giai đoạn này nhằm mục đích chứng minh tính khả thi của giải pháp và chưa đi sâu vào việc cung cấp đầy đủ những chức năng quản lý Cơ sở dũ liệu tương đối đơn giản, gồm 3 bảng: bảng thiết bị, bảng vị trí địa
Bảng thông tin thiết bị
Thông tin của thiết bị được lưu trong bảng device Mỗi thiết bị khi đã đánh mã và đưa vào sử dụng sẽ được lưu vào bảng này để quản lý Các trường thông tin bao gồm: Mã thiết bị
Mã vị trí địa lý Ý nghĩa các trường:
Mỗi thiết bị có một mã duy nhất xác định để phân biệt với các thiết bị khác.
Tên thiết bị chứa thông tin mô tả thiết bị.
Mỗi thiết bị được đặt tại một ví trí địa lý xác định, tại sông, hồ của địa phương. Thông tin này lưu trong mã vị trí địa lý.
Bảng vị trí địa lý
Các khu vực, địa phương, các sông hồ, nơi đặt thiết bị quan trắc môi trường nước, sẽ được đánh mã và lưu trong bảng location Các trường thông tin bao gồm:
Mã vị trí trực thuộc.
Mô tả. Ý nghĩa các trường:
Mỗi vị trí địa lý sẽ có một mã duy nhất xác định để phân biệt với các vị trí khác.
Các vị trí có dạng cây phân cấp, tức là vị trí này có thể nằm trong khu vực của vị trí khác Ví dụ, quận Cầu Giấy thuộc Hà Nội, sông Tô Lịch đoạn chảy qua quận Cầu Giấy, Hà Nội.
Thông tin mô tả chi tiết về vị trí đặt thiết bị.
Bảng thông số môi trường
Dữ liệu thông số môi trường đo được từ thiết bị sẽ được lưu trong bảng measurement Các trường thông tin bao gồm:
Thông số cường độ sang môi trường.
Sơ đồ cơ sở dữ liệu:
Hình 3.3: Cơ sở dữ liệu hệ thống quan trắc 3.4.3 Thiết kế giao diện người dùng Đây là thiết kế về giao diện phần mềm client trước khi lập trình:
Hình 3.4: Thiết kế giao diện client
Vùng 2 : treeview hiển thị danh sách các vùng địa lý và các thiết bị thuộc về vùng địa lý.
Vùng 3: hiển thị thuộc tính của thiết bị, giá trị các số đo hiện tại của thiết bị
Vùng 4: Đồ thị thông số đo của thiết bị.
Vùng 5: Các cảnh báo của server.
3.4.4 Giao tiếp với thiết bị phần cứng
Mọi giao tiếp với thiết bị phần cứng được đóng gói trong lớp TcpServer.
TcpServer sử dụng gói System.Net.Sockets để nhận và gửi các gói tin TCP.
Hình 3.5:Mô hình giao tiếp qua TCP/IP
Như hình vẽ ở trên, các thiết bị gửi các gói tin TCP với nội dung là các đoạn mã nhị phân qua mạng internet đến server Server nhận gói tin, giải mã và đưa ra các xử lý khác như lưu vào cơ sở dữ liệu. Ở trong phạm vi đồ án, dữ liệu trao đổi giữa server và thiết bị chỉ là các số liệu thiết bị đo được gửi đến cho server Khuôn dạng dữ liệu được định nghĩa như sau:
Số đo1|Số đo2|….|Số đo thứ n|Id của thiết bị
Trong đó mỗi số đo là một xâu mô tả một số thực, phần nguyên và phần thập phân ngăn cách bởi 1 dấu chấm (.) , với số âm thì có dấu trừ (-) trước số đo Còn Id thiết bị là xâu chứa số nguyên
Cách làm này đơn giản và phù hợp với yêu cầu của đồ án, tuy nhiên không linh hoạt vì thế yêu cầu phải định nghĩa lại khuôn dạng dữ liệu khi có nhiều loại dữ liệu trao đổi giữa client và server.
3.4.5 Sử dụng SDK để triển khai hệ thống
Sử dụng SDK ở cả 2 phía client và server
Phía Server: Ngoài những công việc tương tự như khi xây dựng TestServer, server trong hệ thống quan trắc cần phải mở rộng không gian nút, tạo ra kiểu đối tượng mới Device, sau đó dựa trên cơ sở dữ liệu của server để tạo ra các đối tượng kế thừa từ Device.
Mô hình thông tin về thiết bị như sau:
Hình 3.6:Mô hình thông tin của thiết bị
Phía Client : Tương tự như TestClient, ứng dụng client của hệ thống quản lý thiết bị cũng sử dụng cơ chế nhận bản tin theo dõi dữ liệu thay đổi.
Một số cách sử dụng dịch vụ để đáp ứng chức năng của client:
- Chức năng lấy danh sách thiết bị: Bằng cách duyệt nút, bắt đầu từ nút kiểu đối tượng Device, đi ngược theo tham chiếu HasTypeDefinition.
Bảng 10: Giá trị các tham số cho dịch vụ Browse ở client hệ thống quan trắc
Tên Giá trị Giải thích
NodeID Mã của nút kiểu Device
ReferenceTypeId NodeId ứng với kiểu
NodeClassMask 0 Tạm thời bỏ qua
ResultMask 63 Tất cả các thuộc tính.
- Chức năng hiện thông tin đo đạc của thiết bị: Bằng cách dùng dịch vụ Read,
Bảng 11: Giá trị các tham số cho dịch vụ Read ở client của hệ thống quan trắc
Tên Giá trị Giải thích
NodeId Mã của nút chứa giá trị đo
AttributeId 13 Mã của thuộc tính Value
IndexRange Bỏ qua Giá trị kiểu scalar
- Chức năng vẽ đồ thị: Bằng cách sử dụng nhóm dịch vụ để đăng ký thu thập dữ liệu Khi cần vẽ đồ thị của thiết bị thì tạo ra một đăng ký mới, trong đó chứa các phần tử tương tứng với giá trị các số liệu đo Chỉ khác với ứng dụng TestClient ở chỗ thay vì hiển thị dạng listview thì dữ liệu hiển thị dưới dạng đồ thị.
Ghép nối hệ thống và kết quả thu được
Hiện nay, hệ thống kết nối đã cơ bản hoàn thiện từ việc truyền nhận dữ liệu từ bên phát đến bên thu, dữ liệu được truyền dưới dạng gói tin TCP, phần mềm đã thực hiện được các chức năng như đã nêu ở trên Đồng thời đã có thiết kế cơ bản về mẫu mã của hộp đựng thiết bị Dưới đây là hình mô tả ghép nói hệ thống:
Hình 3.7:Main của hệ thống
Hình 3.8:Ghép nối phần cứng