BÁO CÁO HỆ THỐNG THÔNG TIN CÔNG NGHIỆP Đề tài Remote Monitoring and Control over the Internet Giám sát và điều khiển từ xa qua Internet

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
VIỆN ĐÀO TẠO SAU ĐẠI HỌC

BÁO CÁO HỆ THỐNG THÔNG TIN
CÔNG NGHIỆP
Đề tài:
Remote Monitoring and Control over the Internet
Giám sát và điều khiển từ xa qua Internet
GVHD : PGS.TS. NGUYỄN VĂN KHANG
SVTH : LÊ HẢI ANH - CB110610
PHẠM VĂN HÀ - CB110616
Lớp : 11BKTĐT
Hà Nội, tháng 6 năm 2012
Mục lục
1. Giới thiệu 2
2. Trường hợp nghiên cứu: Quản lý năng lượng tòa nhà 2
3. Thiết kế hệ thống RBMO 5
4. Phần mềm ứng dụng RBMO 9
5. Thảo luận 10
6. Các công việc có liên quan 15
7. Hướng phát triển 16
8. Kết luận 16
1. Giới thiệu
Giám sát và điều khiển từ xa đề cập đến quá trình giám sát và thu thập dữ liệu tại
các địa điểm từ xa, quá trình xử lý những dữ liệu này, và truyền các thông tin điều khiển
như là một chức năng của quá trình giám sát để tác động đến hành vi của môi trường từ
xa và các thực thể giám sát. Các ứng dụng có thể từ giám sát môi trường (không có điều
khiển) đến bảo mật và các ứng dụng giám sát và ứng dụng điều khiển yêu cầu độ chính
xác cao (ví dụ, điều khiển lò phản ứng hạt nhân, điều khiển năng lượng, và điều khiển
quá trình công nghiệp).
Các dữ liệu từ xa được thu thập thông qua các cảm biến nhúng trong môi trường,

mà hoặc định kỳ truyền về dữ liệu được đo đạc hoặc chuyển các phép đo theo yêu cầu.
Cảm biến được kết nối với hệ thống giám sát và điều khiển thông qua một mạng lưới
thông tin liên lạc. Kết nối mạng có thể là không dây hoặc có dây, chuẩn giao tiếp mạng
có thể là tiêu chuẩn đã có, chẳng hạn như giao thức Internet, hoặc tiêu chuẩn độc quyền.
Vòng lặp điều khiển được xử lý thông qua các thiết bị truyền động để tác động đến quá
trình điều khiển. Hệ thống giám sát và điều khiển có thể được phân tán để tăng khả năng
của hệ thống và bảo vệ chống lại lỗi của một phần nào đó của hệ thống. Các dữ liệu đo
có thể được xử lý tại hệ thống giám sát và điều khiển hoặc bên trong mạng lưới các cảm
biến. Xử lý tại các hệ thống giám sát sẽ là đơn giản cũng như dễ cho việc lưu trữ dữ liệu
vào một cơ sở dữ liệu hoặc giám sát dữ liệu cho các xu hướng bất thường hoặc các sự
kiện đặc biệt. Xử lý dữ liệu ở bên trong mạng các cảm biến có thể đối phó với việc tiền
xử lý thu thập các giá trị đo tại nguồn hoặc tại các nút bên trong mạng lưới các cảm
biến.
Từ các luận điểm ở trên, lĩnh vực ứng dụng thiết kế của hệ thống giám sát và điều
khiển từ xa là rất lớn và sẽ phụ thuộc vào bối cảnh ứng dụng cụ thể. Trong báo cáo này,
chúng tôi chọn một trường hợp nghiên cứu ứng dụng cụ thể, thảo luận và đưa ra ứng
dụng thực tế, và trình bày một bản thiết kế chi tiết của ứng dụng hệ thống giám sát và
điều khiển từ xa. Ứng dụng được nghiên cứu trong trường hợp này là một hệ thống giám
sát và điều khiển hoạt động của các tòa nhà (RBMO) cho việc quản lý nguồn năng
lượng trong các tòa nhà qua mạng Internet. Trường hợp nghiên cứu này đã được xây
dựng hoàn thiện và có kinh nghiệm triển khai trên một số tòa nhà lớn.
2. Trường hợp nghiên cứu: Quản lý năng lượng tòa nhà
2.1. Quản lý năng lượng
Các tòa nhà tiêu tốn một phần ba tất cả năng lượng của Hoa Kỳ với chi phí 200 tỷ
đôla mỗi năm, với 85 tỷ đôla mỗi năm cho các tòa nhà thương mại. Một lượng lớn, có lẽ
đến một nửa số năng lượng này, là lãng phí so với những gì được gọi là chi phí hiệu
quả. Phần lớn lãng phí này có liên quan đến khả năng không thể tối ưu quá trình điều
khiển và vận hành phức tạp các tòa nhà lớn mới được xây dựng hiện nay. Trường hợp
nghiên cứu này cho thấy có thể tiết kiệm thông thường khoảng 15%, và khoảng 40%
năng lượng sử dụng hàng năm có thể tiết kiệm bằng cách kiểm tra, phân tích, và hành

động dựa trên dữ liệu sử dụng năng lượng. Nguồn tiết kiệm lớn nhất phát sinh từ việc tắt
trang thiết bị khi không cần thiết. Những nguồn tiết kiệm khác bao gồm việc lập kế
hoạch sử dụng trang thiết bị tốt hơn và tối ưu hóa điểm đặt điều khiển nhiệt độ.
Các ứng dụng được phát triển trong dự án RBMO dựa trên quá trình sử dụng các
thiết lập và mở rộng chúng sau khi có thông tin thông qua hệ thống điều khiển quản lý
2
năng lượng (EMCSs), sẽ điều khiển hệ thống thiết bị sưởi ấm và điều hòa nhiệt độ
(HVAC) trong các tòa nhà thương mại.
Một số nghiên cứu đã khám phá ra khả năng giám sát của EMCS. EMCSs cho
tòa nhà thương mại là có sẵn. Có hơn 150 nhà sản xuất EMCS. Khoảng 50% các tòa nhà
với trên 45.000 m
2
có EMCS, và họ có mặt trong gần như tất cả các tòa nhà văn phòng
lớn. Đối với các tòa nhà được xây dựng từ năm 1992, gần 50% diện tích mặt sàn trong
các tòa nhà có EMCSs.
Hệ thống RRBMO hỗ trợ giám sát và điều khiển từ xa nhiều tòa nhà, gồm có
HVAC, hệ thống chiếu sáng, v.v thông qua mạng Internet, bằng cách sử dụng CORBA
– giao thức Common Object Request Broker Architecture. Nó được thiết kế để làm việc
với các hệ thống EMCS và HVAC không đồng nhất. Hệ thống RBMO cũng được thiết
kế để tích hợp với trung tâm giám sát và điều khiển tòa nhà từ xa, nơi sẽ cung cấp dữ
liệu trực quan, quản lý cơ sở dữ liệu, mô phỏng việc sử dụng năng lượng và các công cụ
phân tích năng lượng. Các thành phần của hệ thống giám sát từ xa bao gồm:
• Thu thập dữ liệu và máy chủ quản lý cơ sở dữ liệu, được xây dựng trên một hệ
thống Unix.
• Một số phân tích (Unix & Windows) tại các máy trạm, được sử dụng cho dữ liệu
trực quan, phân tích thống kê các dữ liệu, và mô phỏng.
Người sử dụng chính của hệ thống sẽ là chủ sở hữu hoặc nhà điều hành của nhiều
tòa nhà, ví dụ, U.S.GSA, hệ thống trường huyện, trường đại học, chuỗi cửa hàng bán lẻ,
các ngân hàng, các công ty quản lý tài sản.
Hình 1 - Thiết lập hệ thống RBMO

Hệ thống RBMO theo đuổi ba mục tiêu thiết kế chính: chứng minh tính khả thi
kỹ thuật của thiết kế đề xuất, đánh giá và thử nghiệm với công nghệ phần mềm thành
phần và khả năng hoạt động tương tác trên các môi trường không đồng nhất, và trình
diễn các tiện ích của hệ thống.
Sự chú ý chặt chẽ và phân tích cẩn thận các dữ liệu từ EMCSs thông thường có
đủ khả năng để cải thiện hoạt động của tòa nhà, kết quả là cải thiện sự thoải mái cho
người ở trong tòa nhà và giảm việc sử dụng năng lượng. Tuy nhiên, đối với hầu hết các
3
tòa nhà, sự chú ý chặt chẽ và phân tích này không được thực hiện do thiếu phần mềm
thích hợp, thiếu nhà điều hành hoạt động, nhân viên, và các cảm biến không chính xác
hoặc bị hỏng hóc. Hệ thống giám sát từ xa cung cấp khả năng để giảm chi phí lao động
cho việc theo dõi và phân tích EMCSs bằng cách dàn trải các chi phí lao động như vậy
trên một số lượng lớn các tòa nhà. Điều này cũng đem lại tính khả thi về kinh tế để sử
dụng các kỹ sư chuyên gia HVAC.
Việc sử dụng Internet làm cơ sở hạ tầng thông tin liên lạc chính có hai khía cạnh:
sử dụng các giao thức liên lạc Internet và sử dụng mạng Internet.
Việc sử dụng các giao thức mạng Internet cho phép truy cập vào một loạt các
phần cứng tương thích và phần mềm từ nhiều nhà cung cấp khác nhau qua nhiều
phương tiện truyền thông khác nhau. Thị trường Internet rất lớn, với hàng triệu người sử
dụng, vì vậy các nhà cung cấp có thể dễ dàng trừ dần chi phí phát triển. Ngược lại, giao
thức độc quyền thường đòi hỏi chi phí đắt hơn, vì sự thiếu cạnh tranh và bởi vì chi phí
phát triển được trừ dần trên các thị trường nhỏ hơn. Các giao thức công nghiệp cụ thể,
chẳng hạn như BACnet, nằm ở giữa hai thái cực này. Giao thức Internet rõ ràng vẫn là
phổ biến nhất cho các ứng dụng kết nối mạng diện rộng.
Việc sử dụng mạng Internet cho phép người dùng chia sẻ các chi phí cơ sở hạ
tầng liên lạc cơ bản. Khi xây dựng các ứng dụng tự động hóa có thể chia sẻ cơ sở hạ
tầng Internet sẵn có, sự tiết kiệm thực sự đáng kể so với hệ thống điện thoại bàn.
Internet cũng cung cấp triển vọng về truy cập băng thông cao giá rẻ khi cần thiết, ví dụ,
video giám sát từ xa đối với an ninh, hỏa hoạn, hoặc chẩn đoán từ xa. Cuối cùng,
Internet cung cấp sự chắc chắn, đáng tin cậy, kết nối mở rộng.

Nhược điểm của việc sử dụng Internet là sự cần thiết phải có các biện pháp
phòng ngừa an ninh nghiêm ngặt hơn, sẽ thảo luận thêm dưới đây.
EMCS ngày nay được xây dựng chủ yếu để điều khiển. EMCSs là các hệ thống
điều khiển có tính toán mục tiêu đặc biệt, lập trình để vận hành thiết bị tòa nhà như thiết
bị làm lạnh, quạt, máy bơm, van, động cơ, và hệ thống chiếu sáng. EMCSs được cài đặt
cho nhiều mục đích khác nhau như: điều khiển trang thiết bị, hệ thống cảnh báo các trục
trặc trong thiết bị, duy trì các điều kiện cho trước, và cho phép sửa đổi các kỹ thuật điều
khiển.
EMCSs thường giám sát dữ liệu của hoạt động tòa nhà như: vị trí van điều tiết, cá
điểm thiết lập, biến trạng thái của các chất lỏng, và tình trạng thiết bị. Chúng thường
không được sử dụng để theo dõi nhu cầu điện. Trong một số trường hợp, nhiều cảm biến
chính xác có thể cần cho việc chẩn đoán hơn là các cảm biến đã có sẵn trong một
EMCS. Ví dụ, để theo dõi hiệu quả làm lạnh, cần thiết phải có một phép đo chính xác
của việc giảm nhiệt độ và mực nước thông qua thiết bị làm lạnh. Các cảm biến trong
một EMCS thông thường có thể không thích hợp cho tính toán này.
2.2. Xây dựng mô hình dữ liệu tiêu chuẩn
Trong năm 1995, ASHRAE phê duyệt một tiêu chuẩn truyền thông mới, để xây
dựng hệ thống tự động hóa – chuẩn The Building Automation and Control Network
(BAC-net). Tiêu chuẩn này xem các hệ thống HVAC như là một tập các đối tượng. Tuy
nhiên, chuẩn này chưa bao gồm các ứng dụng tiêu chuẩn cấp đối tượng như các thiết bị
làm lạnh hoặc các tháp làm mát. Chúng tôi hy vọng rằng BACnet sẽ sớm được sử dụng
để xây dựng các cổng kết nối cho EMCSs.
International Alliance for Interoperability là một tập đoàn kỹ thuật, kiến trúc, và
là nhà cung cấp các phần mềm xây dựng (ví dụ Autodesk và Bentley Systems), là những
4
người đang làm việc để phát triển một mô hình dữ liệu tiêu chuẩn cho mô tả các tòa nhà.
Mô hình dữ liệu có mục đích sẽ được sử dụng bởi các công cụ thiết kế và kiến trúc, phần
mềm dự toán chi phí xây dựng, phần mềm lập kế hoạch xây dựng, .v.v Chúng tôi đang
theo dõi những nỗ lực này để sử dụng trong các quy ước đặt tên cho các điểm giám sát.
3. Thiết kế hệ thống RBMO

Trong phần này, chúng tôi mô tả kiến trúc của hệ thống RBMO chi tiết hơn nữa,
nguyên nhân chính cho việc quyết định thiết kế, và mô tả các thành phần của hệ thống
dưới đây:
• Hệ thống cổng trong mỗi tòa nhà.
• Hệ thống phụ để thu thập dữ liệu.
• Đặc tả đối tượng cấp ứng dụngvà chuyển đổi đơn vị.
• Cơ sở dữ liệu theo thời gian.
3.1. Kiến trúc hệ thống
Kiến trúc hệ thống RBMO được thể hiện trong hình 2. Nó tạo thành một kiến trúc
ba lớp với các thành phần riêng biệt là: các ứng dụng, hệ thống quản lý cơ sở dữ liệu, và
xây dựng các cổng kết nối. Các lớp riêng biệt là các hệ thống con kết nối với nhau qua
Internet thông qua bộ chuyển đổi CORBA.
Hệ thống này được thiết kế theo kiểu mô-đun để có thể dễ dàng đánh giá các
công nghệ khác nhau cho thành phần cơ sở dữ liệu, giao diện người dùng, và các thành
phần trực quan. Mục này sẽ mô tả các thành phần riêng biệt và thiết kế của chúng một
cách chi tiết hơn nữa.
Hệ thống RBMO tạo thành một hệ thống không đồng nhất kết hợp một số nền
tảng phần cứng khác nhau và hệ điều hành khác nhau, từ hệ thống độc quyền (EMCSs)
đến các nền tảng thông thường (máy trạm Sun/UNIX và PC/Win NT). Tính không đồng
nhất lớn này là một trong những lí do chính cho việc sử dụng CORBA thay vì các giao
thức khác, chẳng hạn như OLE, Active X, DCOM, SNMP, MMS, và giao thức netDDE.
5
Hình 2 – Kiến trúc hệ thống RBMO
3.2. Cổng kết nối
Kiến trúc hệ thống yêu cầu rằng mỗi tòa nhà tham gia có sự hiện diện của một
điểm Internet, cũng được gọi là một cổng kết nối. Các cổng kết nối được đề cập trong
cách thức sử dụng Internet. Bên trong chính cổng kết nối, các đối tượng cụ thể được
xác định bởi một CORBA-compliant Object Request Broker (ORB). Cổng ORB hoạt
động như một trung gian giữa các đối tượng CORBA tham chiếu mới đến và đối tượng
thực tế đang tồn tại trong cổng kết nối. Hiện nay, cổng kết nối là máy tính Pentium-class

PCs chạy hệ điều hành Windows NT.
Một trong những mục tiêu của chúng tôi là trình bày một mạng lưới giám sát tòa
nhà và điều khiển dữ liệu đồng nhất đi qua nhiều tòa nhà - bất kể sự khác biệt về hệ
thống EMCS. Để cung cấp cái nhìn thống nhất ở cấp độ cổng kết nối, cần thiết phải có
giải quyết phân chia kết nối tòa nhà – tòa nhà (ví dụ EMCS đến EMCS) trong quá trình
cổng kết nối tự xử lý. Điều này đã dẫn đến ba phần thiết kế bao gồm một lớp thích ứng
EMCS, một cơ sở dữ liệu dữ liệu nội bộ tòa nhà, và một lớp giao tiếp bên ngoài
CORBA.
Phần cơ sở dữ liệu tòa nhà của cổng kết nối có mục cho tất cả các giám sát tòa
nhà và điều khiển điểm dữ liệu truy cập thông qua EMCS của tòa nhà. Mỗi mục chứa
các thuộc tính cho các đơn vị, tên điểm, và mô tả, cũng như các phương pháp để đọc và
sửa đổi giá trị. Kể từ khi cơ sở dữ liệu này có thể phản ánh chính EMCS, các phương
pháp đã được phát triển để giải mã và tái tạo danh sách dữ liệu điểm cho mỗi nhà cung
cấp cụ thể EMCS. Sự chú ý cụ thể được sử dụng để kết nối các đơn vị thông tin điểm dữ
liệu từ nhà cung cấp hoặc mô tả cài đặt cụ thể đến các tiêu chuẩn. Đơn vị tiêu chuẩn
được yêu cầu cho các cơ sở đơn vị chuyển đổi hệ thống tự động. Kể từ khi nơi hợp lý để
6
giải quyết bất kỳ sự khác biệt về lập bản đồ ở cấp độ tòa nhà, các vấn đề được xử lý bởi
cơ sở dữ liệu cổng nội bộ.
Lớp thích ứng EMCS chịu trách nhiệm cho tương tác với các EMCS tòa nhà
thông qua định dạng giao tiếp cụ thể và các giao thức được yêu cầu bởi nhà cung cấp
EMCS. Trong một số trường hợp, ví dụ Barring-ton EMCS, liên quan đến việc sử dụng
các giao thức tin nhắn độc quyền sử dụng chuẩn giao tiếp truyền thông nối tiếp. Ví dụ
khác, giao tiếp với Johnson Controls EMCS, các giao thức netDDE trên mạng LAN.
Trong mọi trường hợp, định dạng bản tin cụ thể và các thuật toán xử lý được đóng gói
trong các phương pháp liên kết với mỗi phần tử của cơ sở dữ liệu điểm nội bộ, và các
nhà cung cấp khác nhau sẽ không nhìn thấy được ở trên lớp thích ứng EMCS.
Lớp giao diện bên ngoài CORBA cung cấp một lớp thông thường đối tượng C++
mà có thể truy cập vào cổng kết nối ORB. Những đối tượng này có quyền truy cập tối
đa vào cơ sở dữ liệu điểm nội bộ, và có thể thông qua phương pháp thích hợp để truy

vấn các hệ thống EMCS cho giám sát hiện tại và thiết lập các giá trị điểm đặt. Kể từ khi
các đối tượng này hoạt động như là một phần của cổng kết nối ORB và không phải là
một phần của chương trình cổng kết nối, đồng bộ hóa bộ tổng hợp được cung cấp để
đảm bảo truy cập an toàn và độc quyền đến các phương pháp và thuộc tính của dữ liệu
đối tượng tòa nhà.
3.3. Hệ thống thu thập dữ liệu
Dữ liệu từ xa về tình trạng tòa nhà của chúng tôi được khởi tạo có sẵn như là dữ
liệu mặt cắt ngang, có nghĩa là, chúng tôi lấy mẫu trạng thái toàn bộ tòa nhà định kỳ,
thường là khoảng 1-2 phút. Dữ liệu có độ phân giải cao như vậy cho phép chúng tôi
nghiên cứu dao động trong hệ thống điều khiển. Tuy nhiên, phân tích thông thường chỉ
sử dụng một số ít các biến trạng thái, nhưng thường muốn nhìn vào khoảng thời gian dài
của trạng thái mỗi biến đó. Vì vậy, cần thiết phải phân tích mục đích để có các dữ liệu
lưu trữ trong một chuỗi thời gian riêng biệt cho trạng thái mỗi biến.
Câu hỏi được đặt ra là khi nào và nơi nào dữ liệu sẽ được lưu trữ. Điều này có thể
được thực hiện tại thời gian thu thập, thời gian phân tích, hoặc một thời gian trung gian
nào đó.
Chuyển dữ liệu tại thời điểm thu thập sẽ làm chậm quá trình thu thập, nhưng tăng
tốc giai đoạn phân tích. Chuyển dữ liệu tại thời điểm phân tích cho phép thu thập dữ liệu
rất nhanh, nhưng làm chậm giai đoạn phân tích. Chuyển dữ liệu tại thời gian trung gian
cho phép tăng tốc cả hai giai đoạn thu thập và phân tích dữ liệu. Tuy nhiên, kiến trúc
phần mềm trở nên phức tạp hơn và tốn kém để thực hiện và bảo trì. Chuyển dữ liệu có
thể cũng xảy ra tại các cổng kết nối, máy chủ cơ sở dữ liệu, hoặc các máy trạm phân
tích.
Chúng tôi đã chọn để chuyển dữ liệu tại máy chủ cơ sở dữ liệu khi chúng được
thu thập. Điều này sẽ tạo ra ít nhất một hoạt động đọc ghi đĩa cho mỗi dữ liệu điểm giám
sát cho từng điểm lấy mẫu. Đây dường như là kiến trúc dễ nhất để thực hiện, và có hiệu
năng chấp nhận được cho hệ thống nguyên mẫu của chúng tôi.
Hệ thống thu nhận dữ liệu (DAQ) hiện nay là một hệ thống bỏ phiếu nằm trên
máy chủ trung tâm cùng với các hệ thống quản lý cơ sở dữ liệu chuỗi thời gian (DBMS).
Đặt DAQ ở máy chủ rất hữu ích vì lý do hiệu năng như DAQ truyền đạt đáng kể I/O cho

máy chủ cơ sở dữ liệu.
Kiến trúc bỏ phiếu (pull architecture) được lựa chọn khởi tạo rõ ràng vì nó đơn
giản để thực hiện. Chúng tôi chuẩn bị chuyển đến một kiến trúc đẩy (push architecture),
7
mà chúng tôi hy vọng sẽ cung cấp độ tin cậy tốt hơn và dễ dàng hỗ trợ cho các hệ thống
sao chép hoặc phân vùng trung tâm DAQ/DBMS.
Hệ thống thu thập dữ liệu của chúng tôi là đa luồng, với một DAQ phục vụ nhiều
tòa nhà. Điều này cung cấp lợi thế hiệu năng (và giấy phép phần mềm) hơn một quá
trình đơn luồng. Bất cứ lỗi trong quá trình DAQ sau đó gây ra lỗi trong thu thập dữ liệu
từ tất cả các tòa nhà. Sao chép hoặc phân vùng của DAQ rất đáng giá trong các ứng
dụng quy mô lớn.
3.4. Các đơn vị đo lường và khung thời gian
Để làm việc với nhiều tòa nhà, chúng tôi phải đối đầu với sự đa dạng của các đơn
vị đo lường được sử dụng cho các điểm giám sát khác nhau và EMCSs.
Có ba phương pháp tiếp cận để đối phó với vấn đề này:
• Ghi lại tất cả các phép đo như cặp (giá trị, đơn vị).
• Ghi lại đơn vị cho mỗi điểm giám sát như là một phần của siêu dữ liệu cho các
điểm giám sát.
• Ghi lại tất cả các phép đo trong một tập hợp tiêu chuẩn của đơn vị.
Thực hành thông thường trong các hệ thống EMCS là phương pháp 2. Mô hình
dữ liệu AIA thông qua phương pháp 1. Tuy nhiên, các biến thể trong đơn vị đo lường
qua các điểm giám sát và EMCSs được so sánh và tính toán trong DBMS rất khó để xử
lý. Chúng tôi đã thông qua quy ước lưu trữ tất cả các phép đo trong đơn vị tiêu chuẩn SI
(metric) trong DBMS (chuyển đổi được thực hiện bởi hệ thống thu thập dữ liệu). Điều
này đã giải quyết việc tạo các chỉ số và so sánh, tính toán xử lý truy vấn. Chúng tôi dự
định cho phép người dùng sử dụng một hệ thống ưu tiên các đơn vị để hiển thị các kết
quả truy vấn.
Khó khăn tương tự phát sinh với khung thời gian. Có hai vấn đề - việc tập hợp
của các tòa nhà được theo dõi có thể có các múi giờ khác nhau (ví dụ, một chuỗi cửa
hàng bán lẻ lớn) và sử dụng khung thời gian tiết kiệm ánh sáng ban ngày (daylight

savings) sẽ gây ra sự bất bình thường.Chúng tôi giải quyết cả hai vấn đề này bằng cách
chuyển đổi tất cả các nhãn thời gian sang giờ quốc tế (UTC) hay còn gọi là giờ GMT.
Điều này được thực hiện trong hệ thống thu thập dữ liệu trước khi lưu trữ dữ liệu.
3.5. Cơ sở dữ liệu chuỗi thời gian
Số lượng lớn các dữ liệu chúng tôi thu thập sẽ là chuỗi thời gian, ví dụ, nhiệt độ,
sử dụng điện, .v.v Mặc dù các dữ liệu thô có thể là chuỗi thời gian bất thường, chúng
tôi sẽ biến đổi những chuỗi thời gian thông thường để phân tích. Chuỗi thời gian thông
thường giả định thời gian lấy mẫu định kỳ. Do đó, tiêu chí quan trọng nhất để lựa chọn
DBMS là nó phải phù hợp cho dữ liệu chuỗi thời gian và các truy vấn.
Nó có thể hỗ trợ dữ liệu chuỗi thời gian trên bất kỳ một số DBMS: quan hệ,
hướng đối tượng, hoặc lai đối tượng-quan hệ. Việc sử dụng các cơ sở dữ liệu DBMS
quan hệ cho dữ liệu chuỗi thời gian thông thường thường cung cấp hiệu năng tầm
thường, và hỗ trợ yếu cho các hoạt động như làm mịn và lịch. DBMSs hướng đối tượng
cho phép thực hiện các xử lý dữ liệu chuỗi thời gian với sự hỗ trợ tốt hơn cho lịch, làm
mịn, .v.v Để giảm thiểu chi phí phát triển, ban đầu chúng tôi đã chọn một cơ sở dữ liệu
DBMS quan hệ Illustra với hỗ trợ chức năng chuỗi thời gian. Khi DBMS này đã chứng
minh tính không khả thi, chúng tôi chuyển sang một DBMS quan hệ, Oracle.
Hầu hết các dữ liệu không phải là chuỗi thời gian là dữ liệu mô tả tòa nhà - đó là,
Computer Aided Design (CAD), dữ liệu mô tả cấu hình vật lý của tòa nhà, hệ thống
8
HVAC, và hệ thống EMCS. DBMSs hướng đối tượng (OODBMSs) nói chung là tốt hơn
và phù hợp với dữ liệu CAD hơn là DBMSs quan hệ (RDBMSs).
Giao tiếp CORBA, ít nhất là một số triển khai CORBA thương mại, sẵn sàng cho
một vài DBMSs hướng đối tượng, nhưng chưa hỗ trợ cho DBMSs quan hệ hoặc DBMSs
lai quan hệ-đối tượng. Tuy nhiên, Oracle đã thông báo rằng họ dự định để hỗ trợ các
giao tiếp CORBA. Các giao tiếp CORBA bên thứ ba có sẵn cho DBMSs quan hệ.
Hỗ trợ cho cấu hình DBMS máy khách-máy chủ thông thường có sẵn cho tất cả
các DBMSs. Điều này cho phép chúng tôi di chuyển quá trình phân tích và mã trực quan
đến máy PC, máy trạm, trong khi bảo trì dữ liệu cơ sở trên một máy chủ cơ sở dữ liệu
mạnh mẽ.

3.6. Phân vùng hệ thống
Chúng tôi đã giới thiệu giao tiếp CORBA tại một số điểm trong hệ thống. Phân
vùng hệ thống phục vụ 2 mục đích chính:
• Phân phối các thành phần.
• Tách cho tái cấu trúc.
Các giao thức CORBA giữa cơ sở dữ liệu chuỗi thời gian, giao diện đồ họa người
sử dụng, và quản lý thời gian tự động thoát cho phép chúng tôi thay đổi sự phân bố của
các thành phần này tùy thuộc vào băng thông liên lạc và hiệu năng máy khách. Hơn thế
nữa, chúng cho phép chúng tôi tách rời các thành phần riêng biệt cho mục đích tái cấu
trúc, ví dụ như trình duyệt Internet tích hợp giao diện đồ họa.
4. Phần mềm ứng dụng RBMO
Các ứng dụng RBMO được thiết kế để cung cấp ba khả năng sau đây:
• Lưu trữ lịch sử dữ liệu chuỗi thời gian trong một cơ sở dữ liệu.
• Cung cấp một cách trực quan phân tích hiệu suất năng lượng của tòa nhà.
• Thực hiện một loạt các hồi quy và kỹ thuật phân tích thống kê xác định điều kiện
"đường cơ sở" và đánh giá hiệu suất năng lượng sau khi cho thêm, hoạt động và
thay đổi bảo trì, thời gian thay đổi, hoặc để theo dõi lịch sử.
Các ứng dụng lưu trữ và trực quan hiện nay chạy trên các máy trạm Sun với C++.
Chúng tôi hình dung, tuy nhiên, đó là một triển khai tương lai của các ứng dụng trực
quan và phân tích thống kê chủ yếu chạy trên PC, chạy Java trong Windows NT hoặc
một trình duyệt web.
Việc xây dựng và giám sát toàn bộ nhà máy làm lạnh tại một trong những cài đặt
của hệ thống bao gồm hàng chục cảm biến điểm (tổng số khoảng 1500 điểm cảm biến
trong tòa nhà) bao gồm cả hệ thống điện sử dụng, các cảm biến thời tiết, cộng với các
cảm biến trạng thái của sức mạnh máy làm lạnh và tháp làm mát, cảm biến nhiệt độ và
lưu lượng dòng chảy.Chúng tôi thêm một số cảm biến đo lực và lưu lượng, và cảm biến
nhiệt độ vào máy làm mát để so sánh với các cảm biến EMCS ban đầu và làm tăng thêm
thông tin không có sẵn từ EMCS. Tại điểm cài đặt khác, chúng tôi thu thập 120 điểm
giám sát liên quan đến nhà máy làm lạnh, từ tổng cộng 8.000 điểm giám sát bởi các
EMCS.

Chúng tôi đang phát triển một bộ tiêu chuẩn các lô theo dõi hiệu năng cho phép
người dùng xem các dữ liệu lưu trữ với một trình menu thân thiện với người sử dụng.
Điều này bao gồm biểu đồ tải hàng ngày (24 giờ) của dữ liệu hoạt động 5 phút cho tất cả
các giá trị; ngày trong tuần, cuối tuần, và biểu đồ tải hàng tuần (theo giờ dữ liệu); và
biểu đồ tải trung bình hàng tháng. Các thiết bị làm lạnh và máy làm mát sẽ bao gồm các
9
lô như điện năng so với tải làm mát (kW so với tấn) và hiệu quả so với tải (kW/tấn so
với tấn).
Các ứng dụng với mục đích được sử dụng bởi một chuyên gia từ xa. Khả năng
tồn tại cho người sử dụng để xem dữ liệu chi tiết như là chuỗi thời gian của nhiệt độ
nước máy làm mát hoặc quạt tháp làm mát chạy-dừng liên tục. Khái niệm này cung cấp
một công cụ cho một người dùng từ xa chịu trách nhiệm theo dõi hiệu năng của hệ
thống tòa nhà tại nhiều địa điểm. Menu của đồ thị tiêu chuẩn được thiết kế để cho phép
người sử dụng dễ dàng xem các dữ liệu hiệu năng quan trọng nhất, khái quát nhất, trong
khi cung cấp các phương tiện bổ sung để phân tích đầy đủ dữ liệu chi tiết nhất. Nói cách
khác, đồ thị nên cho phép người sử dụng trả lời các câu hỏi "hoạt động của máy làm mát
có tốt không?"
Để mở rộng ứng dụng, chúng tôi phát triển một ngôn ngữ lập trình kịch bản điều
khiển trực quan và có giao diện phần mềm. Một số phần mở rộng và bổ sung có thể
được thực hiện trên mạng, hoặc bởi quá trình chuẩn bị một kịch bản lập trình. Ngôn ngữ
lập trình kịch bản được phát triển đơn giản.
5. Thảo luận
Phần này trình bày chi tiết một trường hợp với kinh nghiệm của chúng tôi trong
việc phát triển, thiết kế, và hoạt động của một hệ thống nguyên mẫu RBMO.
5.1. Khả năng tương tác giữa các nền tảng có liên quan
5.1.1. Khả năng cảnh báo sự kiện
Trung tâm của bất kỳ hệ thống giám sát và điều khiển từ xa là một số cơ chế cho
các địa điểm từ xa cảnh báo đến cho các địa điểm giám sát các sự kiện "đặc biệt". Cảnh
báo sự kiện này phải là tức thời, ổn định, và (thường) nhiều kênh. Một cách lý tưởng,
các sự kiện cần phải được phân loại (để các quá trình nhất định có thể lắng nghe các loại

sự kiện cụ thể).
Dịch vụ cảnh báo sự kiện xác định nhu cầu truyền cảnh báo của những sự cố
đáng kể đến các thành phần hệ thống có liên quan. Tùy thuộc vào yêu cầu hệ thống chức
năng, cảnh báo này có thể xem xét là không đáng tin cậy (ví dụ như giám sát định kỳ
cập nhật giá trị) hoặc có thể được yêu cầu là đáng tin cậy (ví dụ như thiết bị thay đổi
trạng thái). Trong một môi trường phân tán, nơi các thành phần hệ thống có thể lỗi hoặc
không thể truy cập, yêu cầu kỹ thuật để thực hiện các dịch vụ này có thể là đáng kể.
Mặc dù các sự kiện tại giao thức cấp thấp được quy định tại CORBA, ý nghĩa của
việc mô tả và xác định hành vi của sự kiện ở cấp cao vẫn còn giá trị. Sự kiện dịch vụ có
độ tin cậy và cung cấp khả năng ổn định chưa được định nghĩa thống nhất và thực hiện.
Do đó, việc quan trọng là xác định và mô tả một tập hợp con quan trọng của chức năng
dịch vụ sự kiện cấp cao. Những chức năng dịch vụ sự kiện nên được mô tả đầy đủ để
cho phép nhiều cách triển khai với các biểu hiện hành vi tương thích. Một số vấn đề
đang được giải quyết trong đề xuất OMG gần đây để cải thiện dịch vụ cảnh báo sự kiện
Event Notification Services.
5.1.2. An ninh và Bảo mật
Các yêu cầu an ninh chính cho RBMO là để ngăn cản người dùng trái phép thay
đổi các chương trình của các thiết bị HVAC. Bên cạnh việc làm gián đoạn hoạt động
của toà nhà, nó có thể phá hủy thiết bị HVAC với các lệnh không phù hợp (hoặc độc
hại). Do đó, một số chương trình chứng thực an toàn và truy cập điều khiển được yêu
10
cầu. Sự thiếu sót của các chương trình như vậy trong việc triển khai CORBA ở bước đầu
của dự án đã khiến chúng tôi bị chậm trễ trong ứng dụng điều khiển.
Ngoài ra, một số địa điểm đã đưa ra yêu cầu bảo mật dữ liệu sử dụng HVAC (ví
dụ chiếm dữ liệu), và do đó yêu cầu mã hóa tất cả các thông tin liên lạc.
Một trong những mối quan tâm lớn của chúng tôi là khả năng tương tác của các
dịch vụ bảo mật. Chúng tôi đã không thể xác định tính tương tác của dịch vụ phần mềm
bảo mật cho CORBA . Hơn nữa, chúng tôi muốn xây dựng phần mềm tương tác bao
gồm các dịch vụ khác nhau (ví dụ như dịch vụ sự kiện, dịch vụ an ninh, dịch vụ đặt
tên, .v.v ) từ các nhà cung cấp khác nhau. Chúng tôi đã không thể làm như vậy.

5.1.3. Hiệu năng
Kinh nghiệm của chúng tôi với CORBA cho thấy các cơ sở RPC quá chậm để
cho phép các mô hình của hệ thống đo điểm riêng biệt như là các đối tượng riêng biệt.
Nó chứng minh sự cần thiết phải tổng hợp rất nhiều các điểm đo vào bộ thu thập gọi là
"danh sách quét" và truy vấn đến các nhóm các điểm. Trong cơ sở dữ liệu, các truy vấn
này được biên dịch sẵn. Điều này làm giảm đáng kể số lượng các bản tin CORBA, và
cải thiện hiệu năng. Tập hợp những bản tin như vậy dường như là một chiến lược thông
thường để cải thiện hiệu năng của hệ thống phân tán. Tuy nhiên, nó có thể tẻ nhạt và dễ
bị lỗi để thực hiện và bảo trì. Nó buộc người thiết kế phải kết hợp các vấn đề thiết kế
logic và vật lý. Trong khi các ORBs nhanh hơn chắc chắn sẽ hỗ trợ, chúng tôi tin rằng
trễ mạng trong các mạng diện rộng cuối cùng sẽ giới hạn hiệu năng của hệ thống giám
sát một cách trơn tru. Nhiều hệ thống phân tán đã thấy hiệu quả của việc tổng hợp bản
tin.
Các công cụ tự động (hoặc bán tự động) để tập hợp các điểm giám sát riêng biệt
vào đối tượng quét lớn hơn là rất đáng giá. Công cụ như vậy cũng cần thiết để hỗ trợ
giao thức truyền thông quảng bá để gửi nhận bản tin. Công cụ này cho phép tách biệt
thiết kế lôgic và vật lý một cách rõ ràng trong thiết kế và triển khai các hệ thống phân
tán.
Lưu ý rằng nhiều ứng dụng giám sát tòa nhà từ xa yêu cầu hoạt động trên mạng
diện rộng (với độ trễ và băng thông thấp hơn so với các mạng lưới cục bộ).
Một phần vấn đề hiệu năng của chúng tôi xuất phát từ mong muốn cho phép ràng
buộc thời gian chạy của biểu đồ giám sát điểm. Ràng buộc trễ như vậy được coi là cần
thiết để thích ứng với những thay đổi trong cấu hình HVAC (ví dụ do bảo trì, cải tiến,
.v.v ) mà không cần biên dịch lại code RBMO. Chúng tôi đã có thể sử dụng khả năng
yêu cầu linh động của CORBA - tuy nhiên, cảm nhận là hiệu nặng quá chậm đối với yêu
cầu RBMO quy mô lớn.
Cuối cùng, trong ứng dụng này và các ứng dụng liên quan khác như giám sát lưới
điện, thông thường có một nhu cầu để giải quyết với nhiều đối tượng/điểm đang được
theo dõi. Đó là sự hiểu biết của chúng tôi rằng các ORBs hiện nay được cất giữ trong
bảng đối tượng trong bộ nhớ (một vài chục byte cho mỗi đối tượng) cho tất cả các đối

tượng trong hệ thống. Phương pháp như vậy rõ ràng có vấn đề khi nhân rộng cho các bộ
thu thập đối tượng rất lớn. Đây là quan điểm của chúng tôi rằng một số cách lưu trữ tự
động sang bộ nhớ thứ cấp (và liên quan đến con trỏ) tương tự như cơ sở dữ liệu hướng
đối tượng sẽ phải có để hỗ trợ các ứng dụng rất lớn.
5.2. Các vấn đề tích hợp với hệ thống kế thừa
11
Trong việc tích hợp các EMCS xây dựng không đồng nhất thành một hệ thống
phân tán toàn cầu, chúng tôi có thực hiện các giám sát sau.
Đóng gói một hệ thống mang tính kế thừa với các đối tượng có thể ẩn các tính
năng hệ thống thiết yếu rất quan trọng cho cả hệ thống mạnh và hoạt động. Ngay cả khi
người ta có thể ẩn hầu hết các hệ thống phân tán một cách tự nhiên bằng cách sử dụng
công nghệ đối tượng phân tán, các hệ thống cơ bản vẫn còn bao gồm các thành phần
riêng biệt đã được thiết kế như một hệ thống độc lập không có mục đích hợp tác, hoặc
được điều khiển từ quá trình bên ngoài.
Tập trung đầu vào, bảo trì cấu hình và mô tả dữ liệu rất quan trọng. Tính năng
này chủ yếu được phát hiện bởi chính sự vắng mặt của nó. Mặc dù thông tin cấu hình
EMCS có thể tự nhiên được bảo trì bởi hệ thống con đó, các hệ thống này được thiết kế
như các thực thể duy nhất, độc lập. Trong khi nó có thể có khả năng để tạo ra cơ chế tự
động kết hợp thông tin thay đổi cấu hình từ một thành phần (ví dụ EMCS) vào các hệ
thống khác (ví dụ mô phỏng tòa nhà), thông thường không có cơ chế để có tín hiệu hiệu
quả tham gia vào thành phần mà có sự thay đổi được thực hiện. Kết quả là, mặc dù bộ
thu thập của các hệ thống riêng biệt vào một hệ thống đơn lớn hơn được thiết lập thông
qua kỹ thuật phân tán OO, hệ thống mới "lớn hơn" phụ thuộc vào cơ chế điều khiển cao
hơn, khó hơn cho cả hai việc phối hợp và hoạt động đúng đắn.
Khả năng dễ dàng tương tác với các đối tượng trong hệ thống mới này có thể dẫn
đến các thành phần cơ bản hợp tác theo một cách mà sản lượng hoạt động, đồng bộ
chính xác. Kể từ khi các thành phần tương ứng (EMCS, lưu trữ dữ liệu tự động, .v.v )
thường được thiết kế như hệ thống độc lập, chúng thường không có bất kỳ cơ chế đồng
bộ hóa hoặc tín hiệu điều khiển ngoài.Vì vậy, mặc dù có khả năng cho hệ thống của
chúng tôi để có một thành phần theo dõi hiệu năng thiết bị làm lạnh, các yếu tố trong

hiệu ứng thời tiết ngắn hạn, và những thay đổi điểm hoạt động của máy làm mát, không
có cách nào để đảm bảo rằng mỗi thành phần có đường điều khiển độc lập của tất cả các
thành phần hệ thống có liên quan. Một lớp điều khiển có thể được đưa vào kiến trúc,
nhưng kết nối của nó tới tất cả các thành phần hệ thống có thể có vấn đề.
Chúng tôi tin rằng một phần của những vấn đề này có thể được giải quyết bằng
cách có sự hỗ trợ mạnh mẽ từ đặc tả sự kiện, cảnh báo sự kiện, và một thiết kế hệ thống
dựa trên những điều này. Chúng tôi hình dung ra một liên kết không chắc chắn của các
thành phần độc lập gửi và nhận các sự kiện.
5.3. Tính không đồng nhất ý nghĩa và quản lý dữ liệu
5.3.1. Đặt tên và Dịch vụ thư mục
Hiệu quả của mô tả cấu hình và điều khiển là nguyên nhân suy sụp của hệ thống
phân tán. Hệ thống phân tán được xây dựng, một phần, bằng cách liên kết các đối tượng
phân tán trên nhiều nền tảng. Nếu không có một cơ chế để mô tả các liên kết ràng buộc,
dẫn đến hệ thống thiếu tính linh hoạt và tính phức tạp của nó sẽ bị ẩn với tất cả. Cách
đặt tên dịch vụ cung cấp một cách để ràng buộc các tên có ý nghĩa với thực thể đối
tượng.
Những vấn đề có tầm quan trọng lớn hơn trong môi trường điều khiển thời gian
thực, khi hệ thống phải thích ứng với việc thay thế thiết bị và/hoặc nâng cấp theo chu kỳ
cũng như cấu hình lại hệ thống đang hoạt động. Ổn định và đặt tên phổ biến và các dịch
vụ thư mục là một công cụ quan trọng trong việc thiết kế các hệ thống sẽ thỏa mãn
những thay đổi trên. Các ví dụ bao gồm dịch vụ đặt tên CORBA và các dịch vụ thư mục
LDAP.
12
Chức năng của các dịch vụ này đã vượt xa các vấn đề như đặt tên đối tượng cụ
thể và các thuộc tính. Đặt tên phân tán một cách hiệu quả và dịch vụ thư mục có thể
nhìn thấy, thông qua việc sử dụng nhiều lớp nhìn phân cấp, các đối tượng được tập hợp
theo chức năng, vị trí, điều khiển hệ thống phụ, .v.v Ngoài ra, các dịch vụ có thể cung
cấp một kho lưu trữ đơn nhất, phổ biến cho đối tượng siêu dữ liệu. Trong trường hợp
của hệ thống điều khiển, nó có thể bao gồm thông tin về cảm biến và thiết bị sử dụng
trong việc tạo ra giá trị đối tượng, độ phân giải tên đối tượng giải quyết sự khác nhau

của đối tượng địa phương và giám sát không gian tên, và cung cấp cơ chế tự động cho
việc đặt vị trí các thành phần hệ thống điều khiển vật lý và/hoặc lôgic.
5.3.2. Dịch vụ dàn xếp
Trong khi các tiêu chuẩn nỗ lực cung cấp một số hy vọng trong thời gian dài để
hòa giải sự không thống nhất ngữ nghĩa giữa nhiều loại thiết bị mạng và bộ điều khiển
(mạng lưới điện HVAC), sự tồn tại của nhiều điểm không tương thích của các hệ thống
kế thừa yêu cầu cung cấp các điều kiện để kết nối giữa các sơ đồ toàn cục và các sơ đồ
cục bộ. Hiện nay, ví dụ, bên trong RBMO (và các hệ thống khác) thường có một cách
thực hiện đặc biệt với các bảng lập kết nối thủ công. Các điều kiện khác nhau như vậy
được gọi là trung gian (một phần ánh xạ, ràng buộc cuối) hoặc công cụ tích hợp sơ đồ
(ánh xạ gần như hoàn chỉnh, ràng buộc sớm). Các công cụ như vậy yêu cầu truy cập siêu
dữ liệu (ví dụ DB hoặc lược đồ đối tượng). Ví dụ về các công việc liên quan bao gồm
đối tượng OMG Object Interface Repository, và Meta Object Facilities.
5.3.3. Lược đồ tĩnh và động
Thiết kế cơ sở dữ liệu truyền thống xác định lược đồ tĩnh đầy đủ chi tiết. Lược đồ
tĩnh như vậy tạo điều kiện thuận lợi để thiết kế hệ thống, tối ưu hóa truy vấn, .v.v Tuy
nhiên, để theo dõi và điều khiển các ứng dụng, điều đáng giá là khả năng có thể thay đổi
lược đồ (ví dụ như điều chỉnh các loại thiết bị mới) mà không cần xây dựng lại các DB
hoặc biên dịch lại mã. Ví dụ về các cách tiếp cận như vậy bao gồm các hệ thống đại diện
dựa trên khung kiến thức, và liên quan đến giao tiếp linh động của CORBA, cùng với
kho giao diện. Bởi vì khả năng của lược đồ động thông thường là chậm hơn đáng kể so
với giao diện tĩnh, một số nhóm đã xây dựng lược đồ lai - ví dụ bao gồm là International
Alliance for Interoperability (xây dựng mô hình dữ liệu), cung cấp cả hai lược đồ tĩnh
(ví dụ như hình học) và các lược đồ động (khung hình) cho khả năng mở rộng. Có thể
hình dung, kỹ thuật biên dịch nhanh chóng có thể cung cấp một hiệu năng hợp lý.
5.3.4. Dịch vụ chuyển đổi đơn vị
Chúng tôi thấy cần thiết phải cung cấp khả năng chuyển đổi đơn vị đo lường dự
án RBMO của chúng tôi. Chuyển đổi đơn vị có một nguồn gốc xấu về sai sót trong thu
thập dữ liệu/hệ thống quản lý. Sự có mặt khắp nơi của vấn đề này (trong cả đo lường
công nghiệp và kinh doanh thương mại) cho thấy triển vọng như một dịch vụ tiêu chuẩn.

Lý tưởng nhất, người ta muốn một hệ thống mở có thể kết hợp kích thước và chuyển đổi
tự động các đơn vị. Tuy nhiên, đơn vị chuyển đổi không đồng nhất (ví dụ, giữa khối
lượng và thể tích) là phổ biến và rất khó để giải quyết một cách hệ thống.
Sự lựa chọn của chúng tôi là lưu trữ tất cả các phép đo trong các đơn vị tiêu
chuẩn trong DBMS. Trong khi điều này tạo thuận lợi cho việc đánh chỉ số và truy vấn,
nó rất khó để chẩn đoán các lỗi trong hệ thống thu thập dữ liệu.
5.3.5. Giờ khu vực và đồng bộ
13
Đối với các ứng dụng giám sát quy mô lớn, chúng tôi tin rằng ghi lại tất cả thời
gian trong giờ quốc tế (UTC) là cần thiết. Thói quen chuyển đổi múi giờ địa phương,
bao gồm cả thời gian tiết kiệm ánh sáng ban ngày, là rất cần thiết.
Một số giao thức đồng bộ hóa đồng hồ là cần thiết cho hệ thống giám sát. Giao
thức như vậy, ví dụ như NTP, đã được phát triển cho các hệ thống phân tán. Chúng tôi
lưu ý rằng đồng bộ hóa yêu cầu cho giám sát lưới điện là đặc biệt nghiêm ngặt (để đo
lường giai đoạn khác biệt giữa các máy phát điện phân tán theo địa lý) sẽ dẫn đến việc
sử dụng các tín hiệu thời gian GPS để đồng bộ hóa.
5.3.6. DBMS chuỗi thời gian
Triển khai đầu tiên của chúng tôi sử dụng sản phẩm phát hành sớm của Illustra
DBMS, bởi vì nó cung cấp cơ sở vật chất để lưu trữ và truy vấn dữ liệu chuỗi thời gian,
bao gồm cả lịch.Chúng tôi gặp phải vấn đề thực tế với máy chủ DB. Do đó chúng tôi
chuyển sang lưu trữ dữ liệu chuỗi thời gian của chúng tôi trong một cơ sở dữ liệu
DBMS quan hệ có độ tin cậy tốt hơn, là Oracle Version 7.3. Điều này đã giải quyết
được vấn đề độ tin cậy của máy chủ.
Trong khi Illustra cung cấp hỗ trợ trực tiếp cho lưu trữ và truy vấn dữ liệu chuỗi
thời gian, với Oracle, chúng tôi đã xây dựng các cơ sở này trên một hệ thống quan hệ.
Chúng tôi chưa tái tạo lại được tính năng lịch, .v.v Lưu ý rằng Oracle đã công bố các
cơ sở chuỗi thời gian tương tự như Illustra/Informix.
Trong khi Illustra sử dụng lưu trữ xấp xỉ 4 byte/giá trị dữ liệu (số thực), Oracle
hiện nay tiêu thụ khoảng 25 byte dữ liệu/giá trị, bởi vì mỗi dòng dữ liệu có giá trị thời
gian trở thành một hàng đầy đủ trong DBMS.

5.3.7. Đảm bảo chất lượng dữ liệu
Chúng tôi đánh giá quá thấp những khó khăn và nỗ lực cần thiết để đảm bảo chất
lượng dữ liệu thích hợp. Chúng tôi gặp phải một loạt các vấn đề liên quan đến chất
lượng dữ liệu - một số do sai sót trong các đơn vị chuyển đổi, một số do tài liệu bị mất
hoặc sai trong các tập tin cấu hình hệ thống, và một số do vấn đề tràn bộ đếm (16 bit).
Chúng tôi nên quan tâm nhiều hơn nữa đến sự phát triển của phần mềm lọc hệ
thống thu thập dữ liệu. Sự hiện diện của dữ liệu xấu trong cơ sở dữ liệu chuỗi thời gian
là một rào cản đối với việc sử dụng cơ sở dữ liệu thông thường truy vấn để kết hợp. Dữ
liệu xấu là một vấn đề phổ biến trong tất cả các loại ứng dụng kho dữ liệu. Rõ ràng, cách
tiếp cận ưu tiên là làm sạch dữ liệu tại nguồn. Nếu không khả thi, các phương pháp ngắn
gọn, mạnh mẽ là cần thiết để xác định các ràng buộc trên dữ liệu hợp lệ.
5.4. Hoạt động hệ thống
Một nguyên mẫu của hệ thống đã hoạt động hơn một năm. Dữ liệu đã được thu
thập từ hai địa điểm từ xa. Khoảng 1 năm của dữ liệu (cộng với một năm của dữ liệu
lịch sử) được thu thập. Các bộ thu thập dữ liệu có liên quan đến vài chục điểm giám sát
và tốc độ lấy mẫu cho cả hai tòa nhà là một lần trên một phút. Khối lượng thu thập dữ
liệu cơ bản khoảng 1 KB cho mỗi phút.
5.4.1. Soda Hall
Soda Hall, tòa nhà khoa học máy tính với 109,000 ft
2
đã được chọn là địa điểm
nghiên cứu cho trường hợp của chúng tôi vì nhiều lý do. Tòa nhà được trang bị với một
hệ thống điều khiển quản lý năng lượng mà nhóm nghiên cứu đã từng làm việc trước
14
đây. Thứ hai, tòa nhà đã được đặt gần LBNL, cho phép dễ dàng truy cập. Cuối cùng, tòa
nhà có hai thiết bị làm lạnh 220 tấn, tổng cộng 440 tấn với công suất máy làm mát 248
ft
2
/t. Từ sớm trong dự án, chúng tôi đã quyết định tập trung vào thiết bị làm lạnh, đó là
thành phần sử dụng năng lượng lớn nhất trong các tòa nhà với các máy làm mát trung

tâm. Tòa nhà đã phục vụ như là chủ đề của một số nhiệm vụ nghiên cứu mà liên quan
đến vận hành và hiệu năng.
Tổng cộng có 46 điểm được giám sát trong khoảng hai năm, bắt đầu vào tháng chín năm
1995 trong suốt vài tháng đầu tiên bắt đầu có người ở.
5.4.2. Tòa nhà Liên bang Oakland
Tổng cộng có 107 điểm được theo dõi tại Tòa nhà Liên bang Oakland. (Lưu ý,
không phải tất cả các điểm này đều được lấy mẫu, nhiều tính toán bắt nguồn từ các điểm
lấy mẫu chung) Tòa nhà có 1.1 M ft
2
hai tháp, 18 tầng cao ốc văn phòng phức tạp. Tòa
nhà được xây dựng vào năm 1989 và là tòa nhà có các cơ quan liên bang như IRS, Toà
án Mỹ, Bộ năng lượng Hoa Kỳ và Bộ Cựu chiến binh. Tòa nhà được phục vụ bởi một
máy làm lạnh trung tâm với năm thiết bị làm lạnh, ba ở mức 1000 tấn và hai ở mức 450
tấn, tổng cộng 3.900 tấn công suất. Nó chiếm 280 ft
2
/t.
107 điểm bao gồm hệ thống tương tự như ở Soda Hall, bao gồm toàn bộ máy làm
lạnh, xây dựng điện, cộng thêm tháp làm mát, và máy bơm dữ liệu. Điểm bổ sung bao
gồm dòng lặp sưởi ấm, một loạt nhiệt độ bên ngoài từ năm cảm biến xử lý không khí, và
một số cảm biến nhiệt độ khu vực nội bộ.
Một trong những câu hỏi thú vị mà chúng tôi đang kiểm tra tại cả hai địa điểm là
khả năng làm lạnh và quá tải. Các nhà vận hành báo cáo rằng 1000 tấn cuối cùng của
máy làm mát là không cần thiết, ngay cả khi thời tiết nóng nhất.
6. Các công việc có liên quan
Honeywell gần đây đã công bố một hệ thống giám sát tòa nhà mới, khá giống với
dự án của chúng tôi. Atrium sử dụng một hệ điều hành khác nhau và hệ thống Windows
NT và một hệ thống quản lý cơ sở dữ liệu quan hệ khác (SQLServer). Tuy nhiên, chúng
có một kiến trúc tổng thể rất giống nhau. Họ cũng đã chọn để sử dụng (phổ biến) đối hệ
thống quản lý đối tượng phân tán độc quyền, Active X/DCOM, trái ngược với việc sử
dụng hệ thống đối tượng phân tán chuẩn CORBA của chúng ta. Atrium cũng sử dụng

một giao thức truyền thông tự động hóa trong tòa nhà tiêu chuẩn, BACnet, để giao tiếp
với hệ thống EMCS tòa nhà. BACnet là một tiêu chuẩn mới được triển khai. Thiết bị
BACnet EMCSs không có sẵn khi chúng tôi phát triển RBMO.
Sự khác biệt lớn giữa RBMO và Atrium nằm trong cơ sở dữ liệu chuỗi thời gian.
Honeywell chỉ chọn lưu trữ giá trị dữ liệu thay đổi (loại bỏ các phép đo lặp lại). Nó đem
lại kết quả là một chuỗi thời gian nhỏ hơn, nhưng không theo quy tắc. Honeywell cũng
đã triển khai một ngôn ngữ truy vấn chuỗi thời gian đơn giản và thời gian tham gia điều
hành để truy vấn và trích xuất kết nhiều chuỗi thời gian (bất thường).
Hệ thống Enflex từ công ty CTI sử dụng giao thức ứng dụng độc quyền trên
TCP/IP.
Cuối cùng, độc giả cần phải nhận thức rằng quản lý tòa nhà từ xa trình bày nhiều
vấn đề tương tự như việc giải quyết trong quản lý mạng lưới thông tin liên lạc. Hệ thống
quản lý mạng đã sử dụng SNMP và RMON như tiêu chuẩn giao thức truyền thông
chính.
15
7. Hướng phát triển
Chúng tôi dự định sẽ kiểm tra việc sử dụng các dịch vụ an ninh CORBA và HOP
cho điều khiển từ xa các hoạt động HVAC (ví dụ như chứng thực).
Giám sát từ xa của bộ thu thập lớn không đồng nhất trong các tòa nhà đặt ra vấn
đề nghiêm trọng cho phần mềm phân tán của các tòa nhà. Chúng tôi dự định nghiên cứu
phân tán phần mềm tĩnh và động qua Internet trên các nền tảng mục tiêu không đồng
nhất.
8. Kết luận
Chúng tôi đã mô tả việc thiết kế và phát triển của các hệ thống giám sát và hoạt
động các tòa nhà từ xa, trong đó sử dụng giao thức CORBA trên Internet cho thông tin
liên lạc giữa các tòa nhà từ xa, một cơ sở dữ liệu chuỗi thời gian, và các thành phần ứng
dụng riêng biệt phân tán cục bộ trên các máy khác nhau. Chúng tôi đã thảo luận về sự
cân bằng thiết kế, hướng phát triển của chúng tôi và kinh nghiệm hoạt động, và các công
việc có liên quan.
Chúng tôi đã lập luận cho việc sử dụng CORBA trong bối cảnh dự án của chúng

tôi. Chúng tôi đã thảo luận về thiết kế của một hệ thống phân tán để theo dõi các sự kiện
trên khoảng cách lớn, qua nhiều múi giờ, các nguồn không đồng nhất, và đơn vị đo
lường khác nhau. Sự phát triển của cơ sở dữ liệu chuỗi thời gian trên các DBMSs
thương mại đã được mô tả.
Chúng tôi tìm thấy sự cần thiết (vì lý do hiệu năng) phải có tập hợp các điểm
giám sát riêng biệt vào đối tượng lớn hơn cho thu thập dựa trên CORBA. Tập hợp như
vậy là điển hình của các ứng dụng phân tán.
Không DBMS thương mại có sẵn tại thời điểm của dự án chứng minh hoàn toàn
thỏa mãn cho lưu trữ và lấy chuỗi thời gian. Các sản phẩm công bố gần đây có thể khắc
phục vấn đề này.
Các vấn đề nghiêm trọng nhất bao gồm giải quyết không đồng nhất của các
EMCSs tòa nhà khác nhau, các đơn vị và cách đặt tên, các vấn đề với các dữ liệu xấu và
mất dữ liệu. Các nhà phát triển của hệ thống phân tán giám sát cho các hệ thống kế thừa
phải giải quyết được các vấn đề trên hoàn toàn ngay từ đầu trong các dự án của họ.
Cách tiếp cận này dựa trên CORBA là rất khả thi và có tính cạnh tranh so với các
hệ thống khác dựa trên các giao thức truyền thông sở hữu độc quyền. Sự hấp dẫn của
phương pháp tiếp cận của chúng tôi dựa trên sự phổ biến rộng rãi của các sản phẩm
phần mềm thương mại, hỗ trợ các ứng dụng tính toán phân tán dựa trên mô hình
CORBA và giao thức truyền thông Internet cơ bản.
16