Phương pháp thay thế phần cứng bằng phần mềm, những lưu ý đặc biệt khi thay thế; Cơ sở thiết lập tài liệu điều khiển quá trình; Lập tài liệu dự án; Phân tích trình tự các bước thực hiện
Trang 1Copyright 2014 by www.azauto.vn 71 /326 Tutorial
CHƯƠNG 3 : THIẾT KẾ PHẦN MỀM ĐIỀU KHIỂN HỆ THỐNG
Mục đích :
Giới thiệu ngôn ngữ thiết kế phần mềm lập trình xử lý tín hiệu Phương pháp thay thế phần cứng bằng phần mềm, những lưu ý đặc biệt khi thay thế; Cơ sở thiết lập tài liệu điều khiển quá trình; Lập tài liệu dự án; Phân tích trình tự các bước thực hiện chương trình trong dự án lớn
Yêu cầu sau khi học :
1 Nắm được phương pháp thay thế phần cứng, phần mềm
2 Những lưu ý đặc biệt trong việc thay thế
3 Sơ đồ và kết nối tủ điện, nối đất, bọc chống nhiễu và tải cảm
4 Biết được các ý chính trong thiết kế chương trình
5 Có thể thiết lập tài liệu của một quá trình dùng sơ đồ quá trình
6 Có thể lập tài liệu một dự án
7 Có thể phân tích đề ra các bước thực hiện cho chương trình trong một dự án lớn
Số tiết giảng dạy: 4
Bảng phân chia thời lượng :
7 Phương pháp thiết kế phần mềm hệ thống điều khiển trên cơ sở yêu cầu tuần tự :
lưu đồ, phương trình trạng thái, grafcet/SFC, Petri-NET
2
8 Controller design; failsafe, debugging, troubleshooting, forcing
9 Phương pháp lập trình hệ thống lớn
Trọng tâm bài giảng :
1 Các phương pháp thiết kế phần mềm lập trình xử lý tín hiệu dạng logic
2 Phương pháp phân tích, thiết kế các hệ thống lớn
Trang 2
3.1 CÁC NGÔN NGỮ LẬP TRÌNH
Chuẩn IEC 1131 được phát minh làm cơ sở cho việc xây dựng cấu trúc PLC và được chấp nhận bởi hầu hết các công ty và tập đoàn trên thế giới Việc nghiên cứu nắm rõ về nó mở ra khả năng khám phá, lập trình cho các loại PLC
Chuẩn được đăng kí vào năm 1992 và lúc ấy chúng được giới thiệu với tên là IEC-61131 Các thành phần chính của chuẩn bao gồm :
1 IEC 61131-1 Overview
2 IEC 61131-2 Requirements and Test Procedures
3 IEC 61131-3 Data types and programming
4 IEC 61131-4 User Guidelines
5 IEC 61131-5 Communications
6 IEC 61131-7 Fuzzy control
Chuẩn được định nghĩa đủ gần gũi để các công ty vẫn giữ đặc trưng riêng, nhưng cách mô tả
dữ liệu chính tương đối giống nhau
Loại dữ liệu được định nghĩa trong IEC 61131-3
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
Trang 3Copyright 2014 by www.azauto.vn 73 /326 Tutorial
FBD (Function Block Diagram) - A graphical dataflow programming method
SFC (Sequential Function Charts) - A graphical method for structuring programs Hầu hết các công ty đều hỗ trợ các ngôn ngữ này
3.1.1 Ngôn ngữ Ladder
Hình 3.1.1: Ladder Rung (LAD) Language 3.1.2 Ngôn ngữ danh sách lệnh-Instruction List (IL) Language
Hình 3.1.2 : Đoạn chương trình tương đương giữa LAD và IL 3.1.3 Ngôn ngữ Structured Text Programming
Trang 4Structured 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ờ
Hình 3.1.4: Function Block (FBD) Language 3.1.4 Ngôn ngữ lập trình SFC/Grafcet
Trang 5Copyright 2014 by www.azauto.vn 75 /326 Tutorial
Hình 3.1.5 : Ngôn ngữ lập trình SFC
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)
3.1.5 Sự khác biệt giữa SFC và Grafcet
Trang 6Hình 3.1.6 : Sự khác biệt giữa Grafcet và SFC
3.2 CÁC BƯỚC PHÂN TÍCH XÂY DỰNG PHẦN MỀM
Tại sao phải thiết kế chương trình có cấu trúc ?
Thiết kế chương trình có cấu trúc rất quan trọng trong kỹ thuật, nhưng nhiều kỹ sư viết chương trình mà không để dành thời gian hay nỗ lực để thiết kế nó Như vậy, chương trình chỉ phụ thuộc vào kinh nghiệm về chương trình và khả năng gỡ rối của kỹ sư đó Biện pháp này không thể chấp nhận được trong việc xây dựng các hệ thống điều khiển công nghiệp bởi những lý do :
1 Cùng một lúc vừa bị chi phối giữa những việc sử dụng tập lệnh, cách thức lập trình, các điều kiện có thể xảy ra trong hệ thống, Điều này dẫn đến tốc độ lập trình chậm, không dự kiến được các khả năng có thể xảy ra đối với hệ thống
2 Chương trình không có cấu trúc, giải thuật rõ ràng không thể bổ sung, cải tiến, sửa chữa, mở rộng
Thời gian cho một chương trình thiết kế không tốt là 10% cho thiết kế, 30% để viết chương trình, 50% để gỡ rối và kiểm tra, 10% để lập tài liệu Thời gian để thiết kế một chương trình
có chất lượng cao là 30% thiết kế, 20% để viết chương trình, 10% để gỡ rối và kiểm tra, 10%
để lập tài liệu Như vậy, ta thấy rằng một thiết kế tốt tốn ít thời gian thực hiện và bảo trì
Kết luận : Dùng càng nhiều thời gian để thiết kế càng tốt
Các thành phần tham gia vào chương trình điều khiển
Nguyên tắc thực hiện lệnh trong PLC
Trang 7Copyright 2014 by www.azauto.vn 77 /326 Tutorial
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
Hình 3.2.1 : Nguyên tắc thực hiện lệnh trong PLC
Trình tự thiết kế chương trình điều khiển
Hình 3.2.2 : Trình tự thiết kế chương trình điều khiển
3.3 THIẾT KẾ PHẦN MỀM ĐIỀU KHIỂN
Trang 8Mộ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.1 Thiết kế an toàn (Fail Safe Design)
Cần phải dự đoán được hệ thống lỗi thế nào Một số trường hợp lỗi có thể xảy ra như sau :
Kẹt thiết bị - Một thiết bị chấp hành hoặc một khối thiết bị đột nhiên bị kẹt Vấn đề
này có thể dò bằng cách bổ sung cảm biến dò vị trí thiết bị chấp hành hoặc khối đó
Lỗi do người dùng phát hiện – Một số lỗi bất ngờ có thể được xác định bởi người
công nhân Trong các trường hợp đó, người công nhân phải có thể dừng máy dễ dàng
Ngõ vào lỗi (Erroneous) – Dùng cảm biến xác định lỗi
Mode không an toàn (Unsafe modes) – Một vài hệ thống cần được nhập dữ liệu thông
qua công nhân hay đội ngũ bảo trì Thiết bị dò người có thể được kết hợp dùng để ngăn ngừa hoạt động trong khi người đang thực hiện bảo trì thiết bị
Chương trình lỗi (Programming errors) – Một chương trình lớn được không tốt có thể
chạy thất thường khi một ngõ vào tác động không theo dự kiến
Phá hoại (Sabotage) – Với một vài lý do, một vài người có thể cố phá hệ thống Những
vấn đề này có thể được giảm thiểu bằng cách ngăn ngừa truy cập
Lỗi ngẫu nhiên (Random failure) – Mỗi thiết bị có các lỗi ngẫu nhiên khác nhau Ta
phải dự đoán các trường hợp có thể xảy ra để đề ra phương án xử lý nến các thiết bị này bị lỗi
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
Trang 9Copyright 2014 by www.azauto.vn 79 /326 Tutorial
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
3.3.3 Gỡ rối (DEBUGGING)
Gỡ rối bao gồm chạy chương trình, kiểm tra lỗi và sau đó khắc phục nó Một người lập trình
ít kinh nghiệm cần nhiều thời gian để gỡ rối hơn là thời gian lập trình phần mềm Đối với PLC, điều này không thể chấp nhận được! Nếu bạn đang chạy chương trình và nó đang hoạt động sai, nó thường phá hỏng phần cứng Đồng thời, nếu xuất hiện lỗi không rõ ràng, ta phải khảo sát và thiết kế lại chương trình Khi một chương trình được gỡ rối bằng “trial and error”,
có lẽ là có lỗi còn lại trong chương trình, và chương trình khó mà đúng Nên nhớ, lỗi trong chương trình PLC có thể giết chết người người sử dụng
Chú ý : Khi chương trình chạy lần đầu, tốt nhất nên đặt một tay lên nút dừng khẩn cấp (E-stop)
3.3.4 Khắc phục lỗi (Troubleshooting)
Sau khi hệ thống hoạt động, đến một lúc nào đó nó sẽ có lỗi Khi lỗi xảy ra, cần thiết phải xác định và xử lý lỗi nhanh chóng Các bước sau hỗ trợ cách dò tìm lỗi trong hệ thống PLC
1 Quan sát quy trình để biết trạng thái hoạt động bình thường, chẳng hạn như không bị kẹt thiết bị chấp hành, cơ cấu không bị lỗi,… Nếu thấy lỗi, xử lý và khởi động lại hệ thống
Trang 102 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
3.3.5 Gán (Forcing)
Hầu hết các loại PLCs cho phép người dùng gán ngõ vào và ngõ ra Có nghĩa là nó có thể được tích cực mà không cần có tác động vật lý ở ngõ vào hoặc kết quả chương trình Điều này hỗ trợ thuận tiện cho việc gỡ rối chương trình và có thể dễ dàng ngắt hoặc dừng mọi thứ! Phương pháp gán có thể làm cho chương trình hoạt động không hoàn hảo Chúng có thể làm cho ngõ ra được điều khiển không tuần tự Nếu có một lỗi logic, cách này có thể làm cho người lập trình không xác định lỗi
3.4 LẬP TRÌNH HỆ THỐNG LỚN
Để có thể lập trình các hệ thống lớn, ta phải bắt đầu từ các hệ thống nhỏ và hoàn thiện các phương pháp lập trình dùng các kỹ thuật như sơ đồ trạng thái, SFC hoặc PetriNET Hệ thống lớn có thể chứa đến vài trăm loại vấn đề mà ta sẽ thiết kế lập trình dựa trên cơ sở của các phương pháp này Phần này sẽ hướng dẫn để giúp ta biết phương pháp tiếp cận những cách thiết kế này Quan trọng nhất là rõ ràng và đơn giản
Trang 11Copyright 2014 by www.azauto.vn 81 /326 Tutorial
3.4.1 Xây dựng cấu trúc chương trình
Hiểu quá trình sẽ đơn giản được quá trình thiết kế điều khiển Khi hệ thống chỉ được hiểu sơ sài hay gần đúng sẽ dẫn đến xây dựng quá trình trở nên không thể thực hiện được
Những câu hỏi có thể dùng để làm rõ ràng hệ thống, bao gồm :
1 "Có những ngõ vào nào?"
2 "Có những ngõ ra nào?"
3 "Mối liên hệ giữa ngõ vào và ngõ ra?"
4 "Hoạt động của hệ thống có thể sơ đồ hóa được không?"
5 "Thông tin mà hệ thống cần?"
6 "Thông tin về sản phẩm của hệ thống?
Khi một vấn đề điều khiển lớn được chia nhỏ thành những những vấn đề nhỏ Điều này có nghĩa là từng phần nhỏ của hệ thống hoạt động độc lập nhau Điều này có thể đồng thời xảy
ra khi các hoạt động xảy ra trong một quá trình tuần tự không thay đổi Nếu đây là trường hợp vấn đề điều khiển có thể được chia nhỏ thành hai phần đơn giản hơn Câu hỏi được hỏi là:
"Những hoạt động này có bao giờ xảy ra cùng một thời điểm?"
"Hoạt động này có ảnh hưởng đến hoạt động khác?"
"Các hoạt động này có rõ ràng các bước không? "
"Có vấn đề vật lý trong quá trình điều khiển hay thiết bị không? "
Sau khi khảo sát hệ thống, bộ điều khiển phải được chia ra trong hoạt động Tham khảo cấu trúc hình cây trong hình sau Cấu trúc này chia vấn đề điều khiển thành những tác nhiệm nhỏ hơn được thực thi Kỹ thuật này chỉ được dùng để chia để lập trình các tác nhiệm thành những phần nhỏ hơn
Hình 3.4.1 : Sơ đồ chức năng cho điều khiển máy nén
Trang 12Mỗ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ỡ
