Professional Documents
Culture Documents
Chương 3:: Thiết Kế Phần Mềm Điều Khiển Hệ Thống Mục đích
Chương 3:: Thiết Kế Phần Mềm Điều Khiển Hệ Thống Mục đích
Chương 3:: Thiết Kế Phần Mềm Điều Khiển Hệ Thống Mục đích
Bảng 3.1.1: Định nghĩa loại dữ liệu trong chuẩn IEC 1131-3
Loại ngôn ngữ lập trình (IEC 61131-3) có sự liên quan mật thiết với người dùng.
IL (Instruction List) - This is effectively mnemonic programming
ST (Structured Text) - A BASIC like programming language
LD (Ladder Diagram) - Relay logic diagram based programming
Copyright 2014 by www.azauto.vn 72 /326 Tutorial
Status: 18/08 Version 2.2
Tài liệu này được xây dựng để hỗ trợ sinh viên học tập, nghiên cứu. Thông tin liên quan xin liên hệ www.azauto.vn hoặc 0913.586.147
Auto books THIẾT KẾ PHẦN MỀM ĐIỀU KHIỂN HỆ THỐNG No2
Structured text (ST) là ngôn ngữ cấp cao cho phép lập trình có cấu trúc, điều này có nghĩa là
nhiều tác vụ quan trọng có thể chia nhỏ thành nhiều tác vụ con. ST gần giống như ngôn ngữ
BASIC- hoặc PASCAL, trong đó dùng chương trình con để thực hiện các phần khác nhau của
điều khiển và truyền tham số và giữa trị giữa các phần của chương trình.
Hình 3.1.3: Một đoạn chương trình viết theo kiểu Structured Programming
Giống như LD, FBD, và IL, ngôn ngữ ST dùng định nghĩa các biến để xác định các trường
thiết bị ngõ vào và ngõ ra và các biến khác được dùng trong chương trình. ST cũng sử dụng
các vòng lặp, chẳng hạn như WHILE...DO và REPEAT...UNTIL, cũng như các phép toán
điều kiện khác như IF...THEN...ELSE. Nó còn hỗ trợ các phép toán logic như AND, OR, etc.
và đa dạng trong xử lý các loại dữ liệu đặc biệt như ngày, giờ.
Ngôn ngữ Sequential functional chart (SFC) là dạng ngôn ngữ đồ họa cung cấp cách mô tả sơ
đồ của việc tuần tự điều khiển trong chương trình. Về cơ bản, SFC là lưu đồ của các khối
được tổ chức dưới dạng các chương trình con hoặc chương trình nhỏ (được lập trình trong
LD, FBD, IL, và/hoặc ST) hình thành nên chương trình điều khiển. SFC đặc biệt có ích cho
các hoạt động điều khiển tuần tự, trong đó chương trình nhảy từ bước này sang bước khác khi
điều kiện nhảy thỏa mãn (TRUE hoặc FALSE).
Việc thực hiện các lệnh được sắp xếp theo tuần tự từ trái sang phải, từ trên xuống dưới cho
đến khi kết thúc chương trình. Sau đó, việc thực hiện được tiếp tục quay lại từ đầu.
Chú ý : Đây là sự khác biệt dẫn đến sự khác biệt trong lập trình PLC so với cách lập trình
trong vi điều khiển.
Một cách tiếp cận có phương pháp, cẩn thận để thiết kế phần mềm có thể làm giảm thời gian
thiết kế và tạo ra được một hệ thống có độ tin cậy cao.
Cách tiếp cận đó được bao gồm :
1. Thiết kế an toàn.
2. Khả năng gỡ rối.
3. Khả năng khắc phục sự cố.
4. Dùng việc gán trong kiểm tra chương trình.
5. Xây dựng mô hình hệ thống.
3.3.2. Một số lưu ý khi thiết kế : Giúp cải tiến mức độ an toàn của hệ thống.
Chương trình
• Thiết kế an toàn – Chương trình phải được thiết kế để có thể tự kiểm tra lỗi và dừng
trong trường hợp an toàn. Hầu hết các loại PLC có các cảm biến dò lỗi nguồn sắp xảy
ra (imminent power failure sensors), và dùng tác động này khi có nguy hiểm để tắt hệ
thống an toàn.
• Kỹ thuật lập trình phù hợp và lập trình theo module làm hệ thống có thể dò được
lỗi trên giấy thay vì cho nó hoạt động.
• Modular hóa các chương trình được thiết kế.
• Dùng các chương trình không được cấu hình, có thể dự đoán trước.
• Lập trình hạn chế sự truy cập của người không có thẩm quyền.
• Kiểm tra hệ thống trước khi khởi động, cho phép khởi động nếu OK.
• Dùng các chức năng tích hợp trong PLC để dò sai số và lỗi.
Con người
• Cung cấp tài liệu kỹ thuật của hệ thống đang hoạt động, rõ ràng cho người sử dụng và
tổ bảo trì.
• Thực hiện huấn luyện đối với người dùng mới và kỹ sư để giảm việc cẩu thả và lỗi do
không am hiểu về hệ thống.
2. Quan sát PLC để xác định đèn lỗi được tích cực. Mỗi nhà cung cấp PLC đều cung
cấp tài liệu hỗ trợ việc xác định lỗi tương ứng với đèn lỗi. Các lỗi tương ứng được liệt
kê dưới đây. Nếu các đèn cảnh báo ON, xem lại lỗi nguồn của PLC.
HALT – có vấn đề gì đó làm cho CPU dừng.
RUN - PLC hoạt động bình thường (có thể là như thế)
ERROR – lỗi vật lý xảy ra với PLC.
3. Kiểm tra đèn báo trên I/O cards, tương ứng với hệ thống. Chẳng hạn, quan sát cảm
biến on/off, và thiết bị chấp hành on/off, kiểm tra đèn tương ứng trên PLC I/O cards.
Nếu có đèn tương ứng với phần cứng nào đó không sáng, cần kiểm tra lại giao tiếp
điện/cơ.
4. Tham khảo tài liệu hoặc dùng phần mềm nếu có thể. Nếu không có vấn đề nào tồn
tại cụ thể, lỗi chắc chắn sẽ phức tạp, cần đến hỗ trợ kỹ thuật (azauto.corp@gmail.com
– 0913.586147)
5. Nếu với những bước kiểm tra trên không mang lại kết quả, cần liên hệ với nhà cung
cấp hoặc hỗ trợ kỹ thuật.
Mỗi khối trong sơ đồ chức năng có thể được viết dưới dạng các chương trình con riêng biệt
(separate subroutine). Một chương trình cấp cao hơn sẽ gọi các chương trình con nếu cần.
Chương trình có thể được chia thành các phần nhỏ hơn. Cách này làm cho chương trình chính
trở nên gọn gàng hơn, giảm được thời gian thực thi chung (giải thích!!!). Và do chương trình
con chỉ được chạy khi chúng được gọi, sự thay đổi hoạt động do những điều kiện bất ngờ
được giảm xuống. Phương pháp này thường được thực hiện với SFCs hoặc FBDs.
Mỗi chương trình hàm được cho bởi khối riêng bộ nhớ của nó nên không có xung đột trong
chia sẽ bộ nhớ. Dữ liệu của hệ thống hay thông tin trạng thái có thể được đặt trong vùng nhớ
chung. Ví dụ như cờ xác định loại sản phẩm hay phương pháp định hướng hệ thống.
Việc kiểm tra phải được thực hiện trong lúc lên kế hoạch và viết chương trình. Kịch bản tốt
nhất là phần mềm được viết ở những phần nhỏ và sau đó những phần nhỏ được kiểm tra. Điều
này vô cùng quan trọng trong một hệ thống lớn. Khi một hệ thống lớn được viết như một
thành một khối lớn mã, nó trở nên khó khăn hơn để xác định nguyên nhân lỗi.
Thường, ít được quan tâm nhất là tài liệu kỹ thuật (documentation). Tất cả tài liệu kỹ thuật
phải được viết khi viết chương trình. Lời chú thích phải được nhận khi nhập các toán tử LAD.
Điều này làm cho quá trình suy nghĩ rõ ràng và phần mềm ít lỗi. Tài liệu kỹ thuật cần thiết
cho một dự án lớn để phục vụ cho việc bảo trì hệ thống. Thậm chí nếu ta bảo trì nó, ta cũng
có thể quên mục đích nguyên bản thiết kế là gì!
Một vài điều khó khăn không ngờ đến đối với người thiết kế trong những dự án lớn được liệt
kê dưới đây.
Những người thiết kế nghiệp dư lao vào thiết kế bắt đầu công việc dễ dàng, nhưng
những chi tiết họ bỏ qua tốn nhiều thời gian để khắc phục khi họ thực hiện được nữa
quảng đường.
Những chi tiết không được dự đoán và dự án trở nên một tác nhiệm phức tạp, đồ sộ
thay vì nó chỉ là một nhóm các tác nhiệm nhỏ đơn giản.
Người thiết kế viết một chương trình đồ sộ (huge program) thay vì những chương trình
nhỏ. Điều này làm (proof reading) việc đọc lại khó khăn hơn.
Người lập trình ngồi trước bàn phím và gỡ rối bằng “trial and error”. Nếu một người
lập trình đang kiểm tra một chương trình và một lỗi xảy ra, có hai trường hợp có thể
xảy ra. Thứ nhất, người lập trình biết rõ vấn đề lỗi và có thể khắc phục nó tức thời.
Thứ hai, người lập trình chỉ có một ý tưởng lờ mờ, và thường là thực hiện quá trình gỡ
rối bằng phương pháp “trial-and-error”. Nếu thực hiện phương pháp “trial-and-error”
được thực hiện, ta sẽ không hiểu rõ chương trình và nó phải được lập kế hoạch lại.
Các chi tiết nhỏ được để lại để hoàn thành sau. Những chi tiết này có thể để lại mà
không thực hiện, và dẫn đến chương trình lỗi trong hoạt động.
Người thiết kế với những cách tiếp cận không khoa học do cách thiết kế không khoa
học, không nghe lời đóng góp của đồng nghiệp. Điều này thường xảy ra do việc thiết
kế chính là đứa con của họ.
Hiểu biết có giới hạn cũng gây lỗi. Nên nhớ “nếu công cụ duy nhất bạn biết dùng là
chiếc búa thì mọi vấn đề đều giống như chiếc đinh”.
7. Burn-in – Việc kiểm tra này được thực hiện trong một khoảng thời gian dài. Một vài
lỗi chỉ có thể xảy ra khi máy hoạt động trải qua nhiều vòng quét hay trải qua một vài
ngày
Kiểm tra chương trình có thể được thực hiện ngay trên máy, nhưng không phải lúc nào cũng
có thể thực hiện được hay hợp lý. Trong trường hợp này, những phần mềm mô phỏng cho
phép chương trình được kiểm tra không cần máy móc thực tế.
Việc sử dụng một phần mềm mô phỏng dựa theo các bước sau:
1. Ngõ vào và ngõ ra thiết bị được xác định.
2. Mô hình cơ bản của hệ thống là xác định theo nhóm các ngõ vào, ngõ ra. Điều này
có nghĩa là xác định ngõ ra bị ảnh hưởng như thế nào khi ngõ vào thay đổi.
3. Một hệ thống mô phỏng được xây dựng với sự kết hợp một vài phần cứng và phần
mềm đặc biệt.
4. Hệ thống được kiểm tra cho hoạt động mong muốn của hệ thống.
5. Hệ thống sau đó được dùng để kiểm tra phần mềm và kiểm tra hoạt động.