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 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. Copyright 2014 by www.azauto.vn Status: 18/08 81 /326 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 Tutorial Version 2.2 Auto books THIẾT KẾ PHẦN MỀM ĐIỀU KHIỂN HỆ THỐNG No2 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ỡ Copyright 2014 by www.azauto.vn Status: 18/08 82 /326 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 Tutorial Version 2.2 Auto books THIẾT KẾ PHẦN MỀM ĐIỀU KHIỂN HỆ THỐNG No2 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,… Copyright 2014 by www.azauto.vn Status: 18/08 83 /326 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 Tutorial Version 2.2 Auto books THIẾT KẾ PHẦN MỀM ĐIỀU KHIỂN HỆ THỐNG No2 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 Copyright 2014 by www.azauto.vn Status: 18/08 84 /326 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 Tutorial Version 2.2