Thiết kế phần mềm điều khiển hệ thống plc

Auto books THIẾT KẾ PHẦN MỀM ĐIỀU KHIỂN HỆ THỐNG No2

Copyright

2014 by www.azauto.vn 71 /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
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 :
STT
Nội dung
Số tiết
1
Các ngôn ngữ lập trình cho PLC theo chuẩn IEC.
1
2
Các bước phân tích thiết kế phần mềm
1

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.









Auto books THIẾT KẾ PHẦN MỀM ĐIỀU KHIỂN HỆ THỐNG No2

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
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
Auto books THIẾT KẾ PHẦN MỀM ĐIỀU KHIỂN HỆ THỐNG No2

Copyright

2014 by www.azauto.vn 73 /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
 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
Auto books THIẾT KẾ PHẦN MỀM ĐIỀU KHIỂN HỆ THỐNG No2

Copyright

2014 by www.azauto.vn 74 /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
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ờ.

Hình 3.1.4: Function Block (FBD) Language

3.1.4. Ngôn ngữ lập trình SFC/Grafcet
Auto books THIẾT KẾ PHẦN MỀM ĐIỀU KHIỂN HỆ THỐNG No2

Copyright

2014 by www.azauto.vn 75 /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

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

Auto books THIẾT KẾ PHẦN MỀM ĐIỀU KHIỂN HỆ THỐNG No2

Copyright

2014 by www.azauto.vn 76 /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

Hì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
Auto books THIẾT KẾ PHẦN MỀM ĐIỀU KHIỂN HỆ THỐNG No2

Copyright

2014 by www.azauto.vn 77 /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
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
Auto books THIẾT KẾ PHẦN MỀM ĐIỀU KHIỂN HỆ THỐNG No2

Copyright

2014 by www.azauto.vn 78 /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
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.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
Auto books THIẾT KẾ PHẦN MỀM ĐIỀU KHIỂN HỆ THỐNG No2

Copyright

2014 by www.azauto.vn 79 /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
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.
Auto books THIẾT KẾ PHẦN MỀM ĐIỀU KHIỂN HỆ THỐNG No2

Copyright


2014 by www.azauto.vn 80 /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
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 (
– 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.



Auto books THIẾT KẾ PHẦN MỀM ĐIỀU KHIỂN HỆ THỐNG No2

Copyright

2014 by www.azauto.vn 81 /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
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.

Auto books THIẾT KẾ PHẦN MỀM ĐIỀU KHIỂN HỆ THỐNG No2

Copyright

2014 by www.azauto.vn 82 /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
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ỡ
Auto books THIẾT KẾ PHẦN MỀM ĐIỀU KHIỂN HỆ THỐNG No2

Copyright

2014 by www.azauto.vn 83 /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
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”.

3.4.2. Kiểm tra và mô phỏng chương trình
Sau khi chương trình được viết xong, điều quan trọng là phải kiểm tra xem chúng có hoạt
động như mong muốn hay không trước khi nó được dùng như một sản phẩm. Trong những
ứng dụng nhỏ, ta có thể cho nó chạy trực tiếp trên máy và xác định những hoạt động không
phù hợp. Trong những ứng dụng phức tạp, cách tiếp cận này không phù hợp. Cách tiếp cận tốt
để xây dựng phần mềm thực hiện theo các bước sau :
1. Thiết kế cấu trúc – thiết kế và viết phần mềm để có được một tập các mục tiêu rõ
ràng.
2. Kiểm tra các Modular – các đoạn nhỏ chương trình có thể được viết và sau đó được
kiểm tra riêng lẽ. Ta thấy dễ dàng để gỡ rối và kiểm tra hoạt động một chương trình
nhỏ hơn là thực hiện với một chương trình lớn.
3. Duyệt lại mã – duyệt lại các modules mã đúng theo thiết kế. Việc này phải được
thực hiện bằng người khác hoặc ít ra bạn phải tự duyệt lại mã chương trình của bạn.
4. Xây dựng các modular – các modules phần mềm sau đó có thể được thêm và hệ
thống phải được kiểm tra lại. Bất kì vấn đề nảy sinh có thể được gán các thuộc tính để
chỉ hoạt động(inter-actions) với module mới.
5. Xác nhận thiết kế - kiểm tra xem hệ thống có hoạt động như yêu cầu của thiết kế hay
không?
6. Error proofing – Hệ thống có thể được kiểm tra bằng cách thử các tác động lỗi để
quan sát phản ứng của hệ thống. Vấn đề này bao gồm cả việc không gắn cảm biến, kẹt
thiết bị chấp hành, người sử dụng gây lỗi,…
Auto books THIẾT KẾ PHẦN MỀM ĐIỀU KHIỂN HỆ THỐNG No2

Copyright

2014 by www.azauto.vn 84 /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
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.

Tài liệu tham khảo
TIẾNG VIỆT
TIẾNG ANH
 [2]. L. A. Bryan; E. A. Bryan. Programmable Controller Theory and Implementation
Industrial Text Company. 1998.
 [3]. HughJack. Automating Manufacturing Systems with PLCs.2010
 [4]. E.A. Parr, MSc, CEng, MIEE, MinstMC. Programmable Controllers An engineer’s
guide. Newnes. 2003