Giáo trình Hệ thống sản xuất tự động hóa với PLCs - Phần 32: Công nghệ phần mềm
32. CÔNG NGHỆ PHẦN MỀM
Chủ đề:
Các vấn đề đi dây điện: đi dây và bố cục phòng, nối đất, bảo vệ và các tải cảm
ứng
Thiết kế bộ điều khiển: dự phòng, dò lỗi, xử lý sự cố, cưỡng bức
Mô hình hóa quá trình với chuẩn ANSI/ISA-S5.1-1984
Lập trình các hệ lớn
Làm tài liệu
Mục tiêu:
Học các vấn đề chính trong thiết kế chương trình.
Có thể viết tài liệu một quá trình với một sơ đồ quá trình.
Có thể viết tài liệu một dự án thiết kế.
Có thể phát triển một chiến lược dự án cho các chương trình lớn.
32.1 GIỚI THIỆU
Một cách tiếp cận cẩn thận có cấu trúc để thiết kế phần mềm sẽ giảm tổng thời
gian phát triển, và kết quả là một hệ tin cậy hơn.
32.1.1 Thiết kế dự phòng
Là cần thiết để đoán trước các hệ sẽ lỗi như thế nào. Một vài vấn đề thông dụng
mà chúng sẽ xuất hiện được liệt kê ở dưới:
Thành phần mắc kẹt – Một bộ truyền động hay vật thể trở nên bị kẹt. Điều
này có thể được phát hiện bởi thêm các cảm biến cho các vị trí truyền động
và sự hiện diện của vật thể.
Lỗi được phát hiện bởi người vận hành – Một vài lỗi không mong muốn sẽ
được phát hiện bởi người vận hành. Trong các trường hợp đó người vận
hành phải có khả năng dừng máy một cách dễ dàng.
Đầu vào lỗi – Một đầu vào có thể được kích hoạt một cách vô tình. Điều này
có thể bao gồm một số đồ đạc nào đó có thể rơi vào một nút start.
Các chế độ không an toàn – Một vài hệ cần được đi vào bởi các người vận
hành hay đội duy trì. Các bộ dò con người có thể được dùng chống lại hoạt
động trong khi con người đang có mặt.
Các lỗi lập trình – Một chương trình lớn mà nó được viết nghèo nàn có thể
làm việc lỗi khi một đầu vào không dự kiến trước được gặp phải. Điều này
cũng là một vấn đề với các điều kiện khởi động được giả thiết.
Sự phá hoại – Đối với nhiều lý do khác nhau, một vài cá nhân có thể cố gắng
phá hủy hệ thống. Các vấn đề này có thể được tối thiểu hóa bằng cách chống
lại truy cập.
Lỗi ngẫu nhiên – Mỗi thành phần có chiều hướng về các lỗi ngẫu nhiên. Là
đáng giá để xem xét thứ mà nó sẽ xảy ra nếu bất cứ cái nào trong các thành
phần này là lỗi.
Một vài luật thiết kế mà chúng sẽ giúp cải thiện sự an toàn của một hệ được liệt
kê ở dưới:
Các chương trình:
Một thiết kế dự phòng – Các chương trình phải được thiết kế để chúng
kiểm tra cho các vấn đề, và dừng trong các cách an toàn. Hầu hết các
PLC cũng có các cảm biến lỗi nguồn sắp xảy ra, dùng chúng khi bất cứ
nguy hiểm nào hiện diện để làm dừng hệ thống một cách an toàn.
Các kỹ thuật lập trình riêng biệt và các lập trình mô đun sẽ giúp phát
hiện các vấn đề có thể xảy ra trên giấy thay vì trên thực thi.
Các chương trình mô đun thiết kế tốt.
Dùng các chương trình có thể đoán trước được hay các chương trình
không được cấu hình.
Làm chương trình này không thể truy cập cho những người không được
phép.
Kiểm tra cho hệ là OK tại lúc bắt đầu.
Dùng các hàm xây dựng trong PLC cho phát hiện lỗi và hỏng hóc.
Con người
Cung cấp tài liệu rõ ràng và hiện tại cho bảo trì và các người vận hành.
Cung cấp các bài huấn luyện cho các người dùng mới và các kỹ sư để
giảm các lỗi thiếu chú ý và các lỗi không biết trước.
32.2 GỠ LỖI
Hầu hết các kỹ sư đã tham dự một khóa lập trình ở đó họ đã học viết một
chương trình và sau đó dò lỗi nó. Gỡ lỗi bao gồm chạy các chương trình, kiểm thử nó
cho các lỗi, và sau đó sửa nó. Thậm chí một người lập trình có kinh nghiệm là thường
dùng nhiều thời gian cho dò lỗi hơn là viết các phần mềm. Đối với các PLC đây là
không thể chấp nhận được! Nếu bạn đang chạy chương trình và nó đang thực hiện
một cách vô lý nó sẽ thường phá hoại phần cứng. Cũng thế, nếu các lỗi là không rõ
ràng, bạn phải quay trở lại chương trình và kiểm tra lại thiết kế chương trình. Khi một
chương trình được gỡ lỗi bởi thử và sai, có lẽ có các lỗi logic còn lại, và chương trình
này là rất khó để tin cậy. Nhớ rằng, một lỗi nào đó trong một PLC có thể giết chết ai
đó.
Ghi chú: khi chạy một chương trình nào đó lần đầu tiên nó có thể là một ý kiến tốt
cho giữ một tay trên nút e-stop.
32.2.1 Khắc phục sự cố
Sau khi một hệ đang hoạt động nó cuối cùng sẽ lỗi. Khi một lỗi xuất hiện là quan
trọng để có thể nhận ra và giải quyết các vấn đề nhanh chóng. Danh sách sau của các
bước sẽ giúp theo dõi các lỗi trong một hệ PLC.
1. Nhìn vào quá trình này và xem nếu nó trong một trạng thái bình
thường. ví dụ: không có bộ truyền động nào bị kẹt, không có các phần
bị phá, v.v... Nếu có các vấn đề nhìn thấy, sửa chúng và khởi động lại
quá trình này.
2. Nhìn vào PLC để thấy những đèn lỗi nào là bật. Mỗi nhà cung cấp PLC
sẽ cung cấp các tài liệu mà nó chỉ ra các vấn đề nào tương ứng với các
đèn lỗi. Các đèn lỗi thông thường được cho bên dưới. Nếu bất cứ đèn
cảnh báo nào là bật, tìm xem các vấn đề về nguồn điện tới PLC này.
HALT – DỪNG – một vài cái gì đó đã dừng CPU này
RUN – CHẠY – PLC này nghĩ là nó là OK (và có lẽ là thế)
ERROR – LỖI – một vấn đề vật lý đã xảy ra với PLC này
3. Kiểm tra các đèn chỉ thị trên các thẻ vào/ra, xem nếu chúng phù hợp
với hệ. ví dụ, nhìn vào các cảm biến mà chúng là bật/tắt, và các bộ
truyền động bật/tắt, kiểm tra để thấy các đèn trên các thẻ vào/ra PLC
này là phù hợp. Nếu bất kỳ đèn nào không phù hợp với thực tế vật lý,
thì giao diện điện/cơ cần được kiểm tra.
4. Tham khảo các sách hướng dẫn, hay dùng các phần mềm nếu có sẵn.
Nếu không có vấn đề rõ ràng nào tồn tại vấn đề này là không đơn giản,
và yêu cầu cách tiếp cận có kinh nghiệm về kỹ thuật.
5. Nếu tất cả đều hỏng gọi nhà cung cấp (hay nhà thầu) cho giúp đỡ.
32.2.2 Cưỡng bức
Hầu hết các PLC sẽ cho phép một người dùng để cưỡng bức các đầu vào và các
đầu ra. Điều này nghĩa là chúng có thể được bật, bất kể các đầu vào vật lý và các kết
quả chương trình là gì. Điều này có thể thuận tiện cho dò lỗi các chương trình, và, nó
làm dễ dàng hơn cho dừng và phá hủy các vật! Khi các cưỡng bức được dùng chúng
có thể làm chương trình này thực hiện thất thường. Chúng cũng có thể làm các đầu
ra xuất hiện không theo trình tự. Nếu có một vấn đề logic, thì chúng không giúp một
lập trình viên nhận ra các vấn đề này.
Nhiều công ty sẽ yêu cầu tài liệu mở rộng và các quyền trước khi cưỡng bức có
thể được dùng. Tôi không đề nghị cưỡng bức các đầu vào hay các đầu ra, trừ trong
những trường hợp nghiêm trọng nhất.
32.3 MÔ HÌNH HÓA QUÁ TRÌNH
Có rất nhiều kỹ thuật mô hình hóa quá trình,nhưng chỉ một số là phù hợp cho
điều khiển quá trình. Chuẩn ANSI/ISA-S5.1-1984 Piping and In strumentation Diagram
(P&ID) cung cấp các công cụ tốt cho làm tài liệu các quá trình. Một ví dụ đơn giản
được chỉ trong hình 32.1.
Figure 32.1 A Process Model – Một mô hình quá trình
Các ký hiệu được dùng trong các sơ đồ này được chỉ ra trong hình sau:
XXXXXXXXXXXXX. Nhớ rằng các bộ sửa chữa được dùng cho các thiết bị có thể được
cấp cho các thiết bị rời rạc khác.
Các ký hiệu thiết bị rời rạc
Các dụng cụ
Phần được gắn
Khung được gắn
Không thể truy cập hay nhúng
Vị trí phụ, người vận hành có thể truy cập được
Các điều khiển
Hàm máy tính
PLC
Hiển thị/điều khiển được chia sẻ
Figure 32.2 Symbols for Functions and Instruments
Các ký hiệu cho các hàm và các dụng cụ
Các mô hình xử lý này được gán nhãn một cách cẩn thận để chỉ ra chức năng
cho mỗi hàm trong sơ đồ này. Bảng 2 chỉ ra một danh sách các mã chữ thiết bị đo
đạc khác nhau.
XXXXXXXXXXXXXXXXXXXXX
Chữ cái
Chữ đầu tiên
Analysis – Phân tích
Chữ thứ hai
Alarm – Chuông
A
B
C
Burner Combustion - Ổ ghi đốt
User’s Choice – Lựa chọn người
dùng
User’s Choice – Lựa chọn người dùng
Control – Điều khiển
D
E
User’s Choice – Lựa chọn người
dùng
Voltage – Điện thế
Sensor (Primary Element) – Cảm biến
(phần tử chính)
F
Flow Rate – Tốc độ dòng
User’s Choice - Lựa chọn người
dùng
G
Glass (Sight Tube) – Thủy tinh (Ống
trong suốt)
H
Hand (Manually Initiated) – Tay
(được khởi tạo bằng tay)
Current (Electric) – Dòng (điện)
Power – Điện
I
Indicate – Chỉ thị
J
K
Time or Time Schedule – Thời gian
hay thời khóa biểu
Control Station – Trạm điều khiển
Light (pilot) – Ánh sáng (phi công)
L
Level – Mức
M
User’s Choice - Lựa chọn người
dùng
N
O
P
User’s Choice - Lựa chọn người
dùng
User’s Choice - Lựa chọn người dùng
User’s Choice - Lựa chọn người
dùng
Orifice, Restriction – Vòi phun, Hạn
chế
Pressure, Vacuum – Áp lực, Hút
chân không
Point (Test Connection) – Điểm (Kiểm
tra Kết nối)
Q
R
S
Quantity – Số lượng
Radiation – Bức xạ
Record or Print – Ghi hay In
Switch – Chuyển mạch
Speed or Frequency – Tốc độ hay
Tần số
T
Temperature – Nhiệt độ
Multivariable – Nhiều biến
Vibration, Mechanical Analysis –
Phân tích Cơ khí, Rung động
Weight, Force – Trọng lượng, Lực
Transmit – Truyền
U
V
Multifunction – Nhiều hàm
Valve, Damper, Louver – Van, Chống
rung, Mái hắt
W
X
Well – buồng thang máy
Unclassified – Không được phân loại Unclassified– Không được phân loại
Event, State or Presence – Sự kiện, Relay, Compute – Rơ le, Tính toán
Trạng thái hay Hiện diện
Y
Z
Position, Dimension - Vị trí, Chiều
Driver, Actuator, Unclassified – Bộ
điều khiển, Bộ truyền động, Không
được phân loại
Các ký hiệu đường thẳng cũng mô tả các loại của dịch chuyển. Hình 32.3 chỉ ra
một vài đường dịch chuyển phổ biến:
Connection to process – Kết nối để xử lý
Instrument Supply – Cấp dụng cụ
Hydraulic – Thủy lực
Pneumatic – Khí lực
Capillary Tube - Ống mao dẫn
Electric Signal – Tín hiệu điện
EM, Sonic, Radioactive – EM, sóng âm, phóng xạ
Mechanical Connection – Kết nối cơ khí
Software Connection – Kết nối phần mềm
Figure 32.3 Flow Line Symbols and Types – Các ký hiệu và các loại đường dịch chuyển
Hình 32.4 chỉ ra một vài ký hiệu cảm biến và bộ truyền động thông dụng hơn:
Tấm vòi phun
Từ trường
Venturi hay vòi
Máy đo lưu lượng
Van điều khiển
(khí lực kích hoạt)
Figure 32.4 Sensor and Actuator Symbols and Types
Các loại và các ký hiệu cảm biến và bộ truyền động
32.4 LẬP TRÌNH CHO HỆ THỐNG LỚN
Các chương trước đã khám phá các kỹ thuật thiết kế để giải quyết cho các vấn
đề lớn bằng cách dùng các kỹ thuật như là các sơ đồ trạng thái và các SFC. Các hệ lớn
có thể bao gồm hàng trăm loại các vấn đề. Phần này sẽ cố gắng đưa ra một cách tiếp
cận triết lý mà nó sẽ giúp bạn tiếp cận các thiết kế này. Các ý tưởng quan trọng nhất
là đơn giản và rõ ràng.
32.4.1 Phát triển một cấu trúc chương trình
Hiểu về quá trình sẽ đơn giản thiết kế bộ điều khiển. Khi hệ này chỉ hiểu một
phần, hay được định nghĩa một cách mơ hồ quá trình phát triển trở nên lặp đi lặp lại.
Các chương trình sẽ được phát triển, và được sửa chữa cho đến khi chúng là chấp
nhận được. Khi thông tin và các sự kiện được hiểu một cách rõ ràng thiết kế chương
trình này sẽ trở nên minh bạch. Các câu hỏi mà chúng có thể giúp hiểu hệ rõ ràng bao
gồm:
Các đầu vào là gì?
Các đầu ra là gì?
Các trình tự các đầu vào và các đầu ra là gì?
Một sơ đồ của thực hiện hệ thống có thể được vẽ hay không?
Những thông tin gì hệ này cần đến là gì?
Những thông tin gì hệ này sinh ra?
Khi có thể có một điều khiển lớn các vấn đề phải được chia thành các vấn đề
nhỏ hơn. Điều này thường xảy ra khi các vật thể của hệ này làm việc độc lập với các
cái khác. Điều này cũng có thể xuất hiện khi các hành động xuất hiện trong một trình
tự được cố định. Nếu là trường hợp này vấn đề điều khiển có thể được phân chia
thành hai phần nhỏ hơn (và đơn giản hơn). Các câu hỏi để hỏi là:
Các hành động này lúc nào sẽ xảy ra tại cùng thời điểm?
Hành động này sẽ xuất hiện bất kể các hành động khác như thế nào chứ?
Có một trình tự rõ ràng của các hành động không?
Có một phân chia vật lý nào đó trong quá trình này hay máy này không?
Sau khi kiểm tra hệ bộ điều khiển này phải được chia thành các hoạt động. Điều
này có thể được làm xong với một cấu trúc cây như được chỉ trong hình 32.5. Nó chia
nhỏ điều khiển thành các công việc nhỏ hơn mà chúng cần được thực thi. Kỹ thuật
này chỉ được dùng để chia các công việc lập trình thành các phần nhỏ hơn mà chúng
là khác biệt.
(Press: Máy ép, ép; Conveyor in: Băng chuyền đi vào; Pickup bin: thùng tiếp
nhận; part detected: phát hiện vật thể; advance: tiến lên; bin replace: thay thùng; full
detect: phát hiện đầy; adv./retract: tiến/rút lại; idle: chờ không làm gì cả; advancing:
đang tiến; retracting: đang rút)
Figure 32.5 Functional Diagram for Press Control
Sơ đồ chức năng cho một điều khiển máy ép
Mỗi khối trong sơ đồ chức năng này có thể được viết như một chương trình con
riêng biệt. Một chương trình thực thi mức cao hơn sẽ gọi các chương trình con này
khi cần đến. Chương trình thực thi này cũng có thể được chia thành các phần nhỏ
hơn. Điều này giữ cho chương trình chính là nhỏ gọn hơn, và giảm đi tổng thời gian
thực thi. Và, bởi vì các chương trình con chỉ chạy khi nó phải, sự thay đổi trong hành
động không mong muốn được giảm xuống. Đây là phương pháp được thúc đẩy bởi
các phương pháp như là SFC và FBD.
Mỗi chương trình chức năng phải được cấp một khối bộ nhớ cho nó sở hữu để
không có xung đột nào với bộ nhớ dùng chung. Dữ liệu lớn hệ thống hay thông tin
trạng thái có thể được giữ trong các khu vực dùng chung. Các ví dụ điển hình bao
gồm một cờ để chỉ thị một loại sản phẩm nào đó, hay một hệ hướng công thức nào
đó.
Kiểm thử phải được cân nhắc trong lập kế hoạch và viết phần mềm. Kịch bản tốt
nhất là phần mềm này được viết trong các mẩu nhỏ, và sau đó mỗi mẩu được kiểm
thử. Đây là quan trọng trong một hệ lớn. Khi một hệ được viết như một mẩu lớn đơn
lẻ của các mã lệnh, nó trở nên khó nhiều hơn để nhận ra nguồn gốc của các lỗi.
Phát biểu không được quan tâm nhất bao gồm làm tài liệu. Mọi tài liệu phải
được viết khi phần mềm này được viết. Nếu tài liệu này có thể viết đầu tiên, phần
mềm thường là tin cậy hơn và dễ viết hơn. Các chú thích phải được đưa vào khi logic
bậc thang được đưa vào. Điều này thường giúp cho làm rõ các ý nghĩ và phơi bày các
lỗi không cẩn thận. Tài liệu là thiết yếu trong các dự án lớn ở đó các cái khác có khả
năng duy trì hệ này. Thậm chí nếu bạn duy trì nó, bạn có khả năng quên cái thiết kế
ban đầu của bạn dự định là.
Một vài cạm bẫy thông thường được gặp phải bởi các thiết kế viên trong các dự
án lớn được liệt kê ở dưới:
Các thiết kế viên nghiệp dư vội vàng đi qua thiết kế để bắt đầu làm việc
sớm hơn, nhưng các chi tiết họ đã bỏ qua mất nhiều thời gian hơn để
sửa khi chúng được thực thi nửa chừng.
Các chi tiết không được kế hoạch và dự án này trở thành một công việc
phức tạp khổng lồ thay vì các nhóm của các công việc đơn giản nhỏ.
Các thiết kế viên viết một chương trình khổng lồ, thay vì các chương
trình nhỏ hơn. Điều này làm chứng thực đọc khó hơn, và không được
yêu thích lắm.
Các lập trình viên ngồi tại bàn phím và dò lỗi bằng cách thử và sai. Nếu
một lập trình viên đang kiểm thử một chương trình nào đó mà một lỗi
xảy ra, có hai kịch bản có thể. Đầu tiên, lập trình viên này biết lỗi là gì,
và có thể sửa lỗi một các lập tức. Thứ hai, lập trình viên này chỉ có một
ý tưởng mơ hồ, và thường không có tiến bộ nào trong dò lỗi thử và sai.
Nếu lập trình thử và sai tiếp tục chương trình này sẽ không thể hiểu
được, và nó phải được sửa lỗi qua việc lập kế hoạch lại.
Các chi tiết nhỏ hơn là còn lại để hoàn thành sau. Thỉnh thoảng có vài
cái còn lại không được làm, và dẫn tới lỗi khi thực hiện.
Thiết kế là không đông cứng, và các tinh chỉnh nhỏ và các phụ trợ làm
mất một số đáng kể thời gian, và thường dẫn tới các thay đổi thiết kế
chủ yếu.
Các thiết kế viên dùng các hướng tiếp cận không chuyên nghiệp. Họ có
xu hướng theo sau các thiết kế nghèo nàn, chống lại lời khuyên của
đồng nghiệp của họ. Điều này là bình thường vì thiết kế này là đứa con
của họ.
Các thiết kế viên nhận một liều tốt của hội chứng cái không được đặt ra
ở đây. Cơ bản là, nếu ta không phát triển nó, nó phải là không tốt tí
nào.
Các kiến thức giới hạn sẽ gây ra các vấn đề. Việc nói đi “Nếu chỉ công cụ
bạn biết sử dụng thế nào là một cái búa tất cả các vấn đề như là một
cái đinh”.
Giảm cắn nhiều hơn bạn có thể nhai. Một vài dự án là quá tham vọng.
Tránh thêm các bổ sung lộn xộn, và chỉ thấy các sự cần thiết của dự án
này. Thỉnh thoảng một bổ sung không cần thiết có thể làm mất nhiều
thời gian hơn là phần còn lại của dự án này.
32.4.2 Xác minh và mô phỏng chương trình
Sau khi một chương trình đã được viết là quan trọng để xác minh rằng nó làm
việc như được dự định, trước khi nó được dùng trong sản xuất. Trong một ứng dụng
đơn giản đây có thể bao gồm việc chạy chương trình này trên máy này, và tìm kiếm
hoạt động không hợp lệ. Trong một ứng dụng phức tạp cách tiếp cận này là không
phù hợp. Một tiếp cận tốt cho phát triển phần mềm bao gồm các bước sau trong một
thứ tự gần đúng:
1. Thiết kế có cấu trúc – thiết kế và viết phần mềm để gặp một tập rõ ràng
của các mục tiêu.
2. Kiểm thử mô đun – các đoạn nhỏ của chương trình có thể được viết, và
sau đó được kiểm thử một cách độc lập. Là dễ dàng hơn nhiều để dò lỗi
và xác minh hoạt động của một chương trình nhỏ.
3. Duyệt lại mã – duyệt lại mã các mô đun cho tuân thủ thiết kế. Điều này
phải được làm xong bởi các người khác, nhưng tối thiểu bạn phải duyệt
lại mã lệnh của bạn.
4. Xây dựng mô đun – các mô đun phần mềm có thể sau đó được thêm
một tại một thời điểm nào đó, và hệ này được kiểm thử lại. Bất cứ vấn
đề nào phát sinh sau đó có thể được cho là tương tác với mô đun mới.
5. Xác nhận thiết kế - xác minh rằng hệ này làm việc như thiết kế yêu cầu.
6. Chứng thực lỗi – hệ này có thể được kiểm thử bằng cách thử các lỗi
mong muốn và không mong muốn. Khi làm kiểm thử này, các thứ vô lý
cũng phải được xem xét. Điều này có thể bao gồm: các cảm biến không
cắm, các bộ truyền động mắc kẹt, các lỗi người vận hành,v.v...
7. Chạy thử nghiệm – một kiểm thử mà nó tồn tại trong một khoảng thời
gian dài. Một vài lỗi sẽ không xuất hiện cho đến khi một máy đã chạy
trong hàng ngàn chu kỳ, hay qua một vài ngày.
Kiểm thử chương trình có thể được làm xong trên các máy, nhưng điều này
không luôn có thể được hay được mong muốn. Trong các trường hợp này các bộ mô
phỏng cho phép các chương trình này được kiểm thử mà không có máy thực sự.
Sự sử dụng của một bộ mô phỏng điển hình theo sau các bước cơ bản sau:
1. Các đầu vào và các đầu ra máy được xác định
2. Một mô hình cơ bản của hệ này được phát triển về mặt các đầu vào và
các đầu ra. Điều này có thể bao gồm các mục như là khi các thay đổi
cảm biến được mong đợi, các tác động gì các bộ truyền động phải có,
và các đầu vào người vận hành được mong đợi.
3. Một bộ mô phỏng hệ thống được xây dựng với một vài kết hợp của
phần mềm và phần cứng chuyên ngành.
4. Hệ thống này được xác minh cho các hoạt động được mong đợi của hệ
này.
5. Hệ này sau đó được dùng để kiểm thử phần mềm và xác minh hoạt
động ấy.
Một mô tả chi tiết của sự sự dụng bộ mô phỏng là có sẵn [Kinner, 1992].
32.5 TÀI LIỆU
Tài liệu nghèo nàn là một phàn nàn thường thấy được đặt vào các thiết kế viên
hệ điều khiển. Tài liệu tốt được phát triển như một tiến trình dự án. Nhiều kỹ sư sẽ
để tài liệu tới cuối của một dự án như là một lời giải thích về sau. Nhưng, tại điểm đó
nhiều chi tiết đã được quên. Vì thế, nó sẽ mất nhiều thời gian hơn để nhớ lại các chi
tiết của công việc, và báo cáo luôn là thiếu.
Một tập hợp của các dạng thiết kế được cho trong hình 32.6 tới hình 32.12.
Chúng có thể được dùng trước, trong và sau một dự án điều khiển. Các mẫu này sau
đó có thể được giữ trong các văn phòng thiết kế hay duy trì để các cái khác có thể
đạt được truy cập dễ dàng và làm các cập nhật tại lúc bộ điều khiển này được thay
đổi.
Hình 32.6 chỉ ra một trang bìa thiết kế. Nó phải được hoàn thành với các thông
tin như là một tên dự án duy nhất, người liên lạc, và loại bộ điều khiển. Danh sách
của các thay đổi bên dưới giúp theo dõi thiết kế, thiết kế lại và duy trì mà nó được
làm xong cho máy này. Trang bìa này như là một tổng quan nhanh trong lịch sử của
máy này. Hình 32.7 tới 32.9 chỉ ra các trang mà chúng cho phép dạng tự do bản kế
hoạch của thiết kế này. Hình 32.10 chỉ ra một trang của bản kế hoạch các vị trí bộ
nhớ đầu vào đầu ra. Hình 32.11 chỉ ra một trang cho kế hoạch các vị trí bộ nhớ bên
trong, và cuối cùng hình 32.12 chỉ ra một trang cho kế hoạch logic bậc thang. Các
trang này phải được dùng trong thứ tự chúng được cho, nhưng chúng không cần
thiết để tất cả đều được sử dụng. Khi hệ này đã được xây dựng và kiểm thử, một bản
sao của logic bậc thang làm việc phải được đính kèm tới điểm cuối của bó của các
trang.
Figure 32.6 Design Cover Page – Trang bìa thiết kế
(Ghi chú của người gõ: PLC Project Sheet: trang dự án PLC; Project ID: mã dự án;
Start Date: ngày bắt đầu; Contact Person: người liên lạc; PLC Model: Loại PLC;
Attached Materials/Revisions: Các tài liệu/bổ sung kèm theo
)
Figure 32.7 Project Note Page – Trang viết dự án
(Ghi chú của người gõ: Project Notes: Nội dung dự án; System Description: mô
tả hệ thống; I/O Notes: nội dung vào/ra; Power Notes: nội dung về điện; Other
Notes: các nội dung khác.
)
Figure 32.8 Project Diagramming Page – Trang sơ đồ dự án
(Ghi chú của người gõ: Design Notes: nội dung thiết kế; State Diagram: Sơ đồ
trạng thái; Flow Chart: lưu đồ; Sequential Function Chart: biểu đồ chức năng tuần tự;
Boolean Equations: các phương trình Bun; Truth Table: bảng chân lý; Safety: an toàn;
Communications: các truyền thông; Other Notes: các nội dung khác
)
Figure 32.9 Project Diagramming and Notes Page - Trang viết và sơ đồ dự án
(Ghi chú của người gõ: Application Notes: nội dung ứng dụng; Test Plan: kế
hoạch kiểm thử; Electrical I/O: vào ra điện; PLC Modules: các mô đun PLC;
)
Figure 32.10 IO Planning Page – Trang kế hoạch vào ra
(Ghi chú của người gõ: Input/Output Card: thẻ vào ra; Card Type: loại thẻ; Rack
#:giá số; Slot #: khe số;
)
Figure 32.11 Internal Memory Locations Page – Trang các vị trí bộ nhớ trong
(Ghi chú của người gõ: Internal Locations: các vị trí bộ nhớ máy bên trong;
Register or Word: thanh ghi hay từ máy; Internal Word: từ máy bên trong
)
Figure 32.12 Ladder Logic Page – Trang logic bậc thang
Các trang thiết kế này được cung cấp như các ví dụ. Các nhà sản xuất PLC
thường cấp các trang tương tự. Nhiều công ty cũng có các thủ tục tài liệu thiết kế bên
trong của họ. Nếu bạn trong một công ty mà không có các định dạng thiết kế được
chuẩn hóa, bạn phải xem xét thực thi một hệ như vậy.
32.6 VẬN HÀNH
Khi một máy mới đang được chuẩn bị cho sản xuất, hay đã được chuyển đến
bởi một nhà cung cấp nào đó, là bình thường để đi qua một tập hợp của các thủ tục
vận hành. Một vài bước điển hình được liệt kê ở dưới:
1. Kiểm tra trực quan:
Xác minh rằng máy này đáp ứng các mã an toàn trong và ngoài
- các mã điện
- các mã an toàn cho công nhân (ví dụ: OSHA)
Xác định nếu mọi thành phần là hiện diện
2. Lắp đặt cơ khí:
Đặt máy này một cách vật lý
Nối tới các máy liền kề
Nối nước, không khí và các dịch vụ được yêu cầu khác
3. Lắp đặt điện:
Nối đất và và điện nguồn
Các kiểm thử lỗi nối đất và điện thế cao
Xác minh các cảm biến đi vào PLC
4. Kiểm thử chức năng:
Khởi động máy và kiểm thử các dừng khẩn cấp
Kiểm thử cho các chức năng cơ bản
5. Xác minh quá trình:
Chạy máy và làm các hiệu chỉnh để sản xuất sản phẩm
Thu thập dữ liệu khả năng xử lý
Xác định các thủ tục bảo trì được yêu cầu
6. Xác minh hợp đồng/đặc tả:
Xem lại các yêu cầu liên lạc và đánh dấu một cách cá nhân trên mỗi cái
Xem lại các yêu cầu đặc tả và đánh dấu mỗi thứ một cách cá nhân
Yêu cầu rằng bất cứ yêu cầu không tuân theo là được sửa chữa
7. Đặt vào trong sản xuất:
Bắt đầu quá trình trong môi trường sản xuất và bắt đầu dùng bình
thường
32.7 AN TOÀN
32.7.1 Các chuẩn an toàn IEC 61508/61511
THAM KHẢO: McCrea-Steele, R., "Proven-in-Use: Making the right choices for
process safety", Hotlinks, Invensys, Summer 2003.
THAM KHẢO: Eberhard, A, "Safety in Programmable Applications", Automation
World, Nov., 2004.
- Các chuẩn này đề cập đến điện, điện tử, và các hệ điện có thể lập trình được.
- Ba lĩnh vực của các ngôn ngữ phần mềm được đề cập bởi chuẩn này:
+ FPL (Fixed Programming Language) – một tiếp cận rất giới hạn cho lập
trình. Ví dụ hệ được lập trình bằng
cách thiết đặt các tham số.
+ LVL (Limited Variability Language) – một ngôn ngữ với một mô hình lập
trình nghiêm ngặt, như là logic bậc
thang.
+ FVL (Full Variability Language) – một ngôn ngữ mà nó cho truy cập đầy đủ
tới một hệ, như là C.
- Mức toàn vẹn an toàn (Safety Integrity Level - SIL) – các yêu cầu an toàn cho
một chức năng nào đó trong một hệ thống
Yêu cầu thấp:
Mức 4: P=10-4 tới 10-5
Mức 3: P=10-3 tới 10-4
Mức 2: P=10-2 tới 10-3
Mức 1: P=10-1 tới 10-2
Yêu cầu cao hay chế độ liên tục:
Mức 4: P=10-8 tới 10-9
Mức 3: P=10-7 tới 10-8
Mức 2: P=10-6 tới 10-7
Mức 1: P=10-5 tới 10-6
- Các mức an toàn hệ thống được định nghĩa như:
+ SIF (Safety Instrumented Function) – SIL cho mỗi chức năng được lựa chọn
để chắc rằng một chức năng hệ thống tổng thể.
+ SIS (Safety Instrumented System) – Một hệ được kết hợp với một hay
nhiều các bộ xử lý logic.
+ SFF (Safe Failure Fraction) – tỷ lệ của các lỗi an toàn và nguy hiểm được
phát hiện cho tổng các lỗi.
- Để tính toán các SFF:
+ làm một FMEA cho mỗi thành phần hệ trong hệ này.
+ làm rõ các chế độ lỗi như là an toàn hay nguy hiểm
+ tính toán các khả năng của các lỗi an toàn/nguy hiểm (S/D [0, 1])
Tải về để xem bản đầy đủ
23 trang
20061
Free
Bạn đang xem 20 trang mẫu của tài liệu "Giáo trình Hệ thống sản xuất tự động hóa với PLCs - Phần 32: Công nghệ phần mềm", để tải tài liệu gốc về máy hãy click vào nút Download ở trên
File đính kèm:
- giao_trinh_he_thong_san_xuat_tu_dong_hoa_voi_plcs_phan_32_co.pdf
