Điện năng

Good morning,
We ''''re on the same page. Đây là cách nói của dân Mỹ khi họ hoàn toàn đồng ý với nhau trong công việc sau những "heathy disargument". Các anh đã tiến xa trong việc sử dụng cũng như biến đổi PI cho thích hợp với công việc và hoàn cảnh riêng của mình. Tôi vốn không phải là programmer nên thật sự khâm phục những gì các anh đã làm. Nhất là alarm notification, là một vấn đề rất thú vị. Nếu các anh có thể chia sẽ phần mềm đó thì rất hay. Arlam notification của một PI user đang được sử dụng rộng rãi có nhược điểm là phải sử dụng MAPI thông qua Outlook chứ chưa thể trực tiếp sử dùng những hệ thống mail chuyên dụng như Lotus Notes vì vậy automation tuy không đến nổi trục trặc nhưng khá phức tạp. Một yếu điểm khác là nó có limit 10000 points thì phải. Và yếu điểm chính của nó là cái message. Ví dụ khi so sánh hai điểm với nhau khi vượt quá giá trị cho phép thì nó sẽ gửi message ra như không báo giá trị vượt quá mà chỉ có thể báo một digital state. Tất nhiên điều này lệ thuộc nhiều và alarm scheme.
Nhìn vào cái alarm state trên thì sẽ thấy sự phức tạp về deathband vì time. Mặc dù PI có thể nhận được 5 state khác nhau nhưng nó lại không báo state theo hoàn cảnh mà chỉ báo theo cấp bậc. Đây là một trường hợp mà software chưa thể giải quyết.
Về hệ thống PI thì anh rất đúng khi cho rằng cái UDS của nó rất hay. Hôm qua tôi lên Dallas để họp với bên Gas. Họ mua PI cũng đã 6 năm rồi nhưng OSI cũng như IT không thể thuyết phục họ đưa nó vào sử dụng. Gần đây họ có một manager mới nên họ mời tôi lên để nói chuyện với họ nhằm xây dựng hệ thống PI cho họ. Tôi lên đó 1 ngày chủ yếu là trả lời những câu hỏi và suggest những việc cần làm. Chính nhờ câu hỏi hôm nọ của anh là PI có chỗ đứng nào trong hệ thống mà tôi đã có sự chuẩn bị trước. Vector là hệ thống SCADA chính của họ trước nay làm đủ mọi việc nên câu hỏi đầu tiên mà họ muốn biết là tại sau họ phải dùng PI và điều này OSI đã không thuyết phục được họ mặc dù đã bán được software từ 6 năm trước mà toàn ngành chạy đua mua PI. Đúng là UDS là điểm mạnh nhất của hệ thống nhưng nếu chỉ một mình UDS thì không đủ để thuyết phục họ vì bên ngoài có biết bao nhiêu phần mềm có thể cùng làm điều đó hoặc hơn nửa. Ngay cả cái Vector mà họ đang dùng cũng có những khả năng như PI và đang control cả hệ thống. Cái Core system của PI là UDS và datalink-probook. Đây là một hệ thống server-client base hoàn thiện. Khi anh đã sử dụng những hệ thống trending khác thì sẽ thấy được cái hay của probook. Khả năng trend back history của nó cho một thời gian dài vài tháng vài năm trong một thời gian ngắn nhất chính là yếu tố mà nó các business tìm đến với OSI. Nhất là khi hệt thống lên vài chục ngàn tags với hàng trăm, hàng ngàn user thì datalink thật sự có khả năng nổi trội. Lấy ví dụ như anh muốn biết toàn bộ giá trị cao nhất của ngày trong một năm qua của toàn bộ máy biến điện của hệ thống. Ở đây các dữ liệu và phép tính được đưa vào có thể lên đến hàng triệu nhưng PI chỉ mất một thời gian ngắn để đưa ra câu trả lời với một cái nhấn chuột. Chính khả năng của Client apps. mà PI nổi trội hơn các hệ thống khác cũng như bên Server site nó có thể dễ dàng liên kết với các hệ thống database.
Về các ứng dụng khác như module ACE, ICE....nó không thuộc về core system và tôi cũng không sử dụng vì đúng như anh nói chúng có rất nhiều điểm yếu. Tuy không dùng ICE như tôi cũng đã setup ICE trên Citrix cho bên Generation cũng không đến nổi nào nhưng đúng là phải setup cả Microsoft dashboard và SQL server. Về sử dụng tài nguyên thì tôi chưa gặp vấn đề gì ngoài việc khi hệ thống PI chính sửa chửa phải chuyển users sang hệ thống phụ họ có chút lôi thôi.
Nếu như phần mềm của OSI lại xảy ra những vấn đề như lỗi chia cho zero (thật chất là lỗi bộ nhớ) hoặc rò rỉ memory thì họ phải chịu trách nhiệm sửa chửa. Đó là những lỗi căn bản và không thể chấp nhận được đối với bất kỳ một phần mềm nào khi đưa vào phục vụ. Anh có liên hệ để họ giải quyết vì bất kỳ một phần mềm nào của họ đều tính tiền phục vụ dựa trên số point của system. OSI có một đội ngũ developer khá mạnh và cũng chịu khó giải quyết các vấn đề bên client đưa ra. Cũng như vấn đề CPU time quá cao phải được giải quyết. Với tôi CPU time trên 40% là khó chấp nhận với hệ thống real-time vì khi cần sử dụng máy để sửa chữa sự cố lập tức ảnh hưởng đến hệ thống. Interface tôi đang sử dụng là PC của dell loại nhỏ, chỉ 512M memory và single processor nhưng CPU time hầu như chỉ chạy từ 0-10%. Nó chỉ chạy nặng nhất khi phải nối kết đường truyền cho 2 bên và ảnh hưởng mạnh nhất đến nó là hệ thống network. Để truyền tải 45k tags khi chưa sử dụng direct link nó mất khoảng 30 phút để setup vì đoạn đường mà tính hiệu vượt qua khoảng 100 miles và 8 hops. Giờ sử dụng direct link thời gian setup chỉ còn khoảng 5 phút.
Với hệ thống UDS 45k tags CPU cũng chỉ hoạt động từ 2-7% nhưng với UDS cho PI-to-Pi thì CPU time lại là những pulse từ 2-40%. Có rất nhiều thứ ảnh hưỏng đến hoạt động của PI không chỉ riêng phần mềm. Khi hệ thống dưới 25k tags thì memory tăng theo đồ thị linear nhưng khi lên trên 30k tags thì sự tăng tiến của nó sẽ là exponental. Điều này được biết qua thực nghiệm. Khi tôi lên gặp bên GAS họ có một hệ thống UDS rất lớn: 2 processor, 3GM và chỉ chạy 2k tags nhưng khi mở một phần mềm nào thì response time khá lâu. Cái vấn đề của họ là chỗ config cái máy và confict các ứng dụng. IT thường không chấp nhận rằng họ config máy không thích hợp nhưng PI là một hệ thống kỳ quái đối với họ vì chỉ cần xếp đặt không thích hợp sẽ ảnh hưởng mạnh đến hoạt động của máy.
Cấu trúc của RAID5, Mirror đôi khi cũng ảnh hưởng đến khả năng hoạt động của CPU. Marathon mà OSI giới thiệu thực chất không khác gì những loại trên vì khả năng redundance chỉ nằm bên trong một box, nếu cả building bị blow away thì nó cũng tiêu nên đó không thật sự là giải pháp cho vấn đề security và recovery. Buffer là một trong những ưu điểm nhưng của là khuyết điểm của PI. Khi setup buffer vượt qua khả năng hoạt động của interface, 2G thì nó sẽ không hoạt động. Khi buffer quá nhỏ và UDS down quá lâu, buffer sẽ bị full và lúc đó data sẽ viết sang phần khác của hệ thống nó sẽ blow away cả cái API. Cái lỗi này thường được hacker ứng dụng để phá các hệ thống. PI có 2 catches, short term và long term nên cũng giúp ích cho khả năng hoặc động của CPU. Ngoài ra đường truyền luôn có một bottle neck tại Busline, nếu không giải quyết hợp lý sẽ ảnh hưởng đến khả năng của CPU.
PI_OPC là phần mềm của Matrikon ở đây có 3 dạng liên hệ khác nhau tôi không thấy rõ được cấu trúc của hệ thống mà các anh đang dùng. PI_OPC trực tiếp nhận tính hiệu từ device và chuyển tới PI. Lúc này CPU time khá cao là điều có thể hiểu được khi phải luôn luôn lắng nghe các devices. Chính cái bất lợi này mà industry đã không sử dụng PI làm SCADA. Thứ hai là PI_OPC nhận tính hiệu từ OPC server. Lúc này nhiệm vụ của OPC là lắng nghe các devices hay legacy system nên interface chỉ nhằm vào mục đích handsake và buffer là chính nên CPU time cao là điều khó chấp nhận. Với cấu trúc này Matrikon muốn sử dụng OPC để thiết lập MHI và SCADA nhưng họ chưa có chỗ đứng trên thì trường real-time control. Thứ 3 là PI_OPC chuyển đổi bên trên của một protocol khác. Ở đây nó không trực tiếp nói chuyện với bên SCADA mà chỉ nói chuyện với bottom protocol trong cùng môt box. Cấu trúc này khá thành công đang được sử dụng nhiều giống như DNP3 chuyển đổi các protocol của legacy system.
MMI và HMI tuy dễ design nhưng để thật sự có khả năng control in real-time thì các software chạy trên microsoft hầu như chưa đáp ứng được. Tôi được biết có những hệ thống SCADA được xây dựng trên Access.
Được 7604 sửa chữa / chuyển vào 22:59 ngày 06/11/2003

Cảm ơn kekaku.
===============

hình như không upload được nửa
Được 7604 sửa chữa / chuyển vào 21:05 ngày 07/11/2003
Được 7604 sửa chữa / chuyển vào 21:06 ngày 07/11/2003

push

Em nhìn em cũng hiểu hiểu cái schema để alarm. Nó phải có mấy điểm Pre alarm trước khí đạt tới giá trị alarm thực sự.
Em thì em vẫn hơi mù mờ về cái hệ thống SCADA. Em bây giờ đưa ra một tình huống đơn giản thôi. Các bác giải thích hộ em với nhé.
Theo em hệ thống SCADA nó phải có 3 phần chính:
1. Các Terminals là nơi để collect các tín hiệu, hoặc nhận các lệnh điều khiển....
2. Hệ thống điều khiển xử lí tín hiệu tại các trung tâm dispatching. PI chắc phải nàm ở đây.
3. Hệ thống communication để nối 2 cái lại với nhau.
Trên đây chỉ là cài phần cứng thôi, để cái đống này nó làm việc thì chắc còn rất nhiều thứ thuộc về phần mềm nữa. Nhưng em cứ bắt đầu thế này cho nó Basic.
Các bác có đồng ý thế không ạ. Nếu các bác đồng ý với ý kiến của em. Các bác hãy thử nói một chút về các thiết bị terminal tại một cái substation 220 kV được không ạ ? Sơ đồ cấu trúc, phuơng thức quản lí thu thập tín hiệu, nếu có thể phưong thức để truyền tín hiệu về trung tâm dispatching...v.v. Các thứ mà các bác cho nó liên quan đến cái trạm ấy.
Em đợi trả lời của các bác.

tạm thời sau khi viết xong thì tống một phát cho nó ra.
============

Cái mô hình trên tôi lập ra để giải quyết yêu cầu của khách hàng. Pre-alarm là tại thời điểm mà giá trị vựơt qua giá trị cho phép. Phần lớn các alarm system đều alarm tại thời điểm này, nhưng vấn đề đặt ra là nếu như tính hiệu chỉ vượt qua giá trị cho phép rất ít và lại rớt xuống rồi trồi lên....nếu cứ alarm như vậy thì một ngày hệ thống báo động và người nhận sẽ bị quá tải. Phần lớn các software giải quyết vấn đề này bằng đặt ra một deadband. Khi tính hiệu giao động trên khỏang giá trị đó thì sẽ không báo động họat không release alarm. Ở đây tôi sử dụng một khỏang thời gian nếu như giá trị vẫn luôn giữ bên trên giá trị cho phép thì sẽ báo động. Mỗi một mô hình có điểm mạnh yếu khác nhau, và mô hình này được tôi chọn vì nó thích hợp với những công việc của khách hàng thông qua thử nghiệm. Các relay system cũng có các deadband và thời gian pick-up nhưng hầu như không có một mô hình nào hòan chỉnh.
Ví dụ ngày hôm qua chúng tôi điều tra về sự cố dây dẫn của bên phân phối. Mọi người có những câu chuyện khác nhau như relay của phase C feeder 1 nhìn thấy giá trị vượt nên ngắt sau 4 phút. Hoặc feeder bị ảnh hưởng nên 2 tiếng sau lại bị ngắt...tất cả những stories trên làm rối lọan mọi thứ và những câu hỏi tại sau relay mất hơn 4 phút để ngắt dòng điện và thật sự chỉ có mình phase C feeder 1 có vấn đề? sự liên quan nào giữa 2 feeders và tại sao lại mất hơn 2 tiếng để tạo ra tạo ra dữ kiện thứ 2...
- Sau nhiều cuộc gọi vẫn không có kết quả cho đến khi tôi dùng PI để xem xét các tính hiệu truyền tải. Trước thời điểm xảy ra dữ kiện 1 phase C feeder 1 tải khỏang 250A rồi đột phát lên trên 700A cho tới khi ngắt mạch khỏang 500A hơn 4 phút sau. Relay đã không thấy rõ sự thay đổi vì tính hiệu nằm trong deadband và di chuyển qua lại giữa khỏang cho phép và không cho phép. Relay thứ hai là ground relay hay neutral one cũng không bắt đựơc và mọi người không hiểu tại sao. Sau khi tôi sắp xếp lại các số liệu và tính ra neutral current trong suốt thời gian 4 phút đó thì một lần nữa các giá trị này nằm trong khỏang deadband trên dưới 480A. Vì vậy mạch chỉ bị ngắt sau hơn 4 phút khi thời gian cho phép bị vượt quá bởi phase C feeder. Tuy là một trường hợp hy hữu nhưng tất cả mọi thứ đều có thể xảy ra.
- Cái vế thứ hai là tại sau mất hơn 2 tiếng để ảnh hưởng feeder thứ hai và có sự liên quan gì cũng được thấy sau khi chồng dữ liệu của hai feeder lên nhau theo thời gian. Khi feeder 1 ngắt mạch feeder 2 lại pick-up một lượng Amps không lớn lắm và rớt xuống rồi lại pick-up...cứ như vậy cho đến khi ngắt mạch. Ở đây rõ ràng có sự liên hệ và theo bên distribution thì feeder 2 nằm bên trên feeder 1 một khỏang cách an tòan. Tuy nhiên với những dữ liệu thì khả năng phóng điện giữa hai feeders là rất có thể. Và khi lấy tất cả dữ liệu của 7 ngày trước lên màn hình tôi thấy được có sự liên hệ giữa hai feeder vào ngày thứ năm tuần trước khi cả hai phase A của hai feeders jumping around theo một chu kỳ nhất định và đó là ngày duy nhất trong suốt tuần cho đến khi xảy ra sự cố. Tôi nghĩ rằng đó là ảnh hưởng của điều kiện khí hậu bên ngòai vì trong những ngày cuối tuần gió rất mạnh. Tuần đó xếp và tôi cùng một đồng sự có ra ngòai ăn và hôm đó gió rất mạnh. Tôi tìm người đồng sự và cô ta nhớ đó là ngày thứ 5 đúng với những gì tôi nghĩ. Ở đây rất khó nói rằng ảnh hưởng của ngày thứ 5 đã tạo ra sự kiện trên những rõ ràng trong ngày lạnh lượng điện tiêu thụ nhiều hơn bình thường dây điện sẽ vòng xuống và gặp gió đã tạo ra những arcing giữa hai bộ dây dẫn. Điều này xảy ra khi lực trên dây dẫn không đúng như thiết kế phần lớn do winding arm control nên dây dẫn đung đưa quá mức cho phép. Dữ kiện đầu xảy ra do short circuit không hòan tòan nên cường độ tăng đột biến nhưng lại không lớn lắm và khi feeder một bị ngắt thì feeder 2 vẫn chịu ảnh hưởng nên cộng thêm một lượng nhỏ cường độ lên dây của nó đã dẫn đến dữ kiện 2 sau hơn 2 giờ....
Đây chỉ là những sự phức tạp khó ngờ trong ngành điện và những gì tôi viết lên đây chỉ là ý kiến cá nhân vì tất cả tài liệu không thuộc quyền sở hữu của tôi nên ý kiến chính thức về những dữ liệu thu được thuộc về người có thẩm quyền của công ty nếu như phải ra tòa khi cần thiết. Ở đây tôi chỉ muốn nói lên khả năng của PI applications nếu được sử dụng đúng có thể làm được rất nhiều và một điều nửa là không có một mô hình nào hòan chỉnh mà luôn đòi hỏi phải tạo ra những mô hình tùy theo từng hòan cảnh theo một mục đích chung. Hầu hết những dữ kiện mà tôi điều tra bằng PI đều khác nhau và luôn có những kết quả bất ngờ vì SCADA không đưa ra được những bằng chứng một cách rõ ràng. Tuần tới tôi sẽ có present về PI và sự liên quan giữa các hệ thống với nhau để đưa tính hiệu từ end-device đến màn ảnh của người sử dụng.
====================

SCADA được diễn giải theo nhiều cách khác nhau nhưng nếu nhìn theo cách giải thích của communication và câu hỏi của bạn thì có thể nói như sau: Dựa vào khả năng truyền thông và điều khiển mà ta có một hệ thống SCADA.
Khi search trên internet theo các vendor về phần mềm thì SCADA gắn liền với HMI - Human Machine Interface. Tại Mỹ thì có các hệ thống của Seimen, Intellution của GE, Substation Solution của Qualitrol....và tôi cũng có xem qua một số phần mềm tạo HMI của Trung Quốc. Ngay cả Access cũng được sử dụng để tạo một HMI rẻ tiền. HMI là phần mềm điều khiển thông qua hình ảnh trên trên màn hình. Một trong những yếu tố quan trọng của SCADA còn là hệ thống MMI - Main Machine Interface.
Nếu theo cách phân biệt của bạn thì ta có thể chia ra như sau:
- Hệ thống real-time gồm có các RTUs và trung tâm RTDS
- Hệ thống điều khiển EMS, Emergency Managment System là bộ phận chính của SCADA - HMI.
- Communication là cột sống xuyên suốt của hệ thống nó là một function hơn là một hệ thống chính. Nó có thể biệt lập nhưng có mặt khắp mọi nơi.
- Có thể VN dùng PI làm cơ sở dữ liệu nhưng phần lớn PI nằm sau hệ thống SCADA chủ yếu là phục vụ người dùng.
RTU có thể lấy tính hiệu của 2 substations ngược lại 1 substation cũng có thể có 2 RTU. Tuy nhiên trên thực tế thường thì một substation chỉ có 1 RTU và ngược lại. Cái chính của substaiton là máy biến điện. Máy biến điện là một trong những thiết bị lẽ đắc tiền nhất trong truyền tải và quyết định sự họat động của đường truyền. Đây là nơi bắt đầu của các tính hiệu. Trung bình một substation có khỏang 20-30 tính hiệu khác nhau được lấy qua các sensor khác nhau và có những scalling factor cũng như filter khác nhau. Những sensor này được nối vào RTU cũa substation thường bằng dây dẫn thông qua tính hiệu dòng điện.
Từ đây tính hiệu được upload lên RTDS thường là qua modem line hay khá hơn thì dùng LAN. Để hiệu tính hiệu của các sensor các RTUs dùng những protocol khác nhau nên RTDS sẽ là nơi tập trung tính hịêu cũng như chuyển giải tính hiệu để chuyển về MHI theo một protocol chung. Converstion xảy ra giữa các devices với RTU cũng như giữa RTU với RTDS và RTDS với HMI đòi hỏi chính xác và delay rất nhỏ để có thể được gọi là real-time. Thực tế chỉ có hệ thống near real-time chứ không thể nào có hệ thống real-time.
Nếu chỉ nói về RTU thì mỗi RTU tùy thuộc vào từng vendor riêng chẳng hạn như ION, Hathaway....RTU configuration bên này là việc của kỷ thuật viên tôi chỉ giúp họ setup hệ thống khi cần nên không rõ lắm. Nhưng thông qua những tài liệu mà họ đưa thì cũng không khác gì setup computor. Nếu muốn nói về thiết kế một RTU lại là vấn đề khác.
Sơ đồ cấu trúc thì cũng chẳng có gì đặc biệt trừ khi là bạn muốn thiết kế, nếu không nó chỉ là một thiết bị truyền thông. Phần lớn các RTU đều tự động trừ khi dispatcher nhúng tay vào. Tính hiệu thu nhập lựa trên nhiều phương thức khác nhau như scan rate, on-demand, rate of change....còn truyền tính hiệu thì phải nói đến internetworking. Để hai hệ thống "đồng lọai" hiểu được nhau thì thông qua một thứ gọi là native interface. Đây là một điều rất quan trọng khi quyết định sử dụng một phần mềm mới vào hệ thống. Để hai hệ thống không đồng lọai hiểu nhau thì thông qua một middleware. Cái interface này sẽ tìm hiểu tính hiệu đầu vào và chuyển tải tính hiệu đầu ra. Chẳng hạn OPC_PI có nghĩa là một interface nhận tính hiệu từ OPC set rồi sang PI set để truyền tải đến PI.
Thôi đi ăn cái đã, gặp sau nghe. À tôi sắp có một số câu hỏi về hệ thống điện VN, hy vọng các bạn có thể giúp. Trong truyền tải "Tag" là một vấn đề rất quan trọng được hiểu theo nhiều cách khác nhau. Tôi muốn tìm những thông tin liên quan về trạm điện, tỉnh, thành...tất cả những cái này điều liên quan và ảnh hưởng đến việc xây dựng một hệ thống SCADA cũng nhưng tích hợp các hệ thống. Tôi sẽ có những câu hỏi chi tiết sau.
===================

quên, tống cho nó một phát.
==============

Lâu mới vào lại topic này. Hệ thống EMS chính là trung tâm của một hệ thống SCADA. Bác 7604 có thể trình bày cụ thể hơn về cái này không ạ ? Ví dụ chức năng, phương thức hoạt động, cấu trúc... nói chung là tất cả những cái mà bác cho liên quan. Em nghe nói nhiều về nó rồi mà vẫn chưa hình dung nó ra sao cả. Mong các bác chỉ giáo.