Các thức triển khai dự án MBD (Simulink Based)

Xin chào các bạn, mình xin giới thiệu bài viết của tác giả Billy Bob về MBD, đây là bài viết mình cho là hay nhất và dễ hiểu nhất từ trước đến nay khi đọc về MBD. Anh là người Việt Nam (tên tiếng Việt là Bảo: https://www.linkedin.com/in/bao-nguyen-4373aa17), hiện đang làm việc cho công ty Mathworks. Cảm ơn Anh Bảo rất nhiều!

https://openmbd.com/

Model Based Design (MBD): MBD tức là dùng graphical model để thiết kế complex system như là control system, signal processing system, communication system. 

Ví dụ, bạn đang học Mechatronic engineering. Bạn cần thiết kế/thi công con robot bưng phở (gọi tắt là: RBP). Con robot thì bạn mua đồ về lắp ráp, chế tạo. Phần điều khiển sẽ là hệ thống nhúng.

Theo MBD thì bạn sẽ dùng Simulink để mô hình hóa (modelling) con RBP. Cái RBP model đó có hai phần là Control Model và Plant Model. Control Model dùng để mô phỏng phần điều khiển, Plant Model dùng để mô phỏng con robot. Khi mô phỏng xong xuôi thì bạn sẽ test nó xem hoạt động như thế nào: đi đứng, bưng phở, chào hỏi khách như ý của chủ tiêm phở không? Khi RBP model của bạn passed hết các tests thì bạn có thể dùng Simulink Embedded Coder để Generate code cho hệ thống nhúng. Lúc này bạn đã lắp ráp xong con robot thì cắm cái card điều khiển, sử dung same test cases cho RBP model để test con robot và hiệu chỉnh các tham số (tune control parameters). Khi passed hết tests thì ship con robot bưng phở đến cho chủ quán phở.

 Đọc đến đây thì sẽ có nhiều bạn sẽ hỏi. Tại sao ta không ráp con robot, program thẳng trên nó là xong? Đúng rồi, bạn có thể làm như vậy. Nhưng MBD sẽ mang đến cho bạn nhiều cái lợi ích sau đây:

- Bạn cần tiền cho dự án. Khi đi gặp các chủ quán phở, model chạy trên laptop + phần graphics thì dễ thuyết phục (convince) chủ quán bỏ tiền ra hơn là PowerPoint slides

- Bạn có thể dùng nó để nắm bắt các yêu cầu về chức năng (capture functional requirements) từ chủ quán ví dụ như tốc độ, đi đứng, giong nói, cách ứng xử ....

- Bạn có thể dùng nó để nắm bắt các yêu cầu không phải là chức năng (capture non-functional requirements) như là giá cả của từng bộ phận, transmission delay khi dùng wired hay wireless communication giữa các bộ phận của con robot…

- Khi có hết requirements thì bạn sử dụng Model để cân nhắc lựa chọn thiết kế: Design tradeoff analysis; Size, Weight, Power and Cost (SWaP-C) analsysis, Mean Time Between Failures (MTBF) analysis để báo giá cho chủ quán và đồng thời cho khách hàng biết khi nào sẽ cần bảo dưỡng định kỳ.

- Nói chung cùng một cái model, bạn có thể sử dụng nó để nói chuyên vói khách hàng, vendors bán hàng robot, kỹ sư phần mềm, kỹ sư phần cứng. Ai cũng có thể bấm nút (hit play button) để coi nó hoạt động và tune nó theo ý mình.

 Trước khi nói sâu thêm vể MBD, tôi sẽ nói sơ qua về Waterfall model, một software development cycle rất thông dụng. Đầu tiên là thu thập các yêu cầu hệ thống (gathering system requirements). Khi có các yêu cầu đó (system requirements) thì bạn viết software high level requirements. Để có đầy đủ thông tin để design, bạn cần phải viết thêm low level requirements và bắt đầu làm premilinary design và detailed design. Lúc này để tìm lổi thiết kế và hiểu để code thì bạn sẽ phải review một đống three-letter-word documents: SSS, SRS, SDD, ICD, STD … Cực nhất là phải sit through requirement design review, đọc vài trăm trang giấy để yêu cầu người viết sửa cho đúng để bạn có thể code cho đúng. Trong khi viêt code hay unit test, nếu bạn phát hiện lỗi hay customer thay đổi thiết kế thì phải sửa SSS, SRS, SDD, ICD, STD lại cho đúng. Nhiều công ty sử dụng agile process tức là viết requirements vừa đủ để thiết kế, thiết kế vừa đủ thì code, code vừa đủ thì unit test, unit test xong thì viết tiếp requirements. Khi code hết các modules thì làm software – software integration, software – hardware integration. Nói chung đến khi run được system level testing thì cũng gần cuối project. Lúc này mà phát hiện ra lổi hệ thống thì toang ông giáo ạ.

MBD workflow có 4 phần chính: Requirements, Model, Source Code, Object Code. MATLAB/Simulink cung cấp đầy đủ toolboxes để bảo đảm verification & validation cho từng phần.

1. Requirements: requirement ở đây là High Level Requirement. Bạn dùng Simulink Requirement để viết và quản lý requirements.

a. Requirements phải được review để đảm bảo tính rõ ràng, dể hiểu, cân đo, đong đếm được. Quan trọng nhất là phải test được. Đây là cái manual step mình phải làm. Hiện tại chưa có AI nào có thể thay thế con người làm việc này.

b. Mỗi requirement sẽ đươc gán một cái unique ID dùng để reference sau này

2. Model: model ở đây là Simulink model, MATLAB code chỉ là một phần của model (MATLAB function block)

a. Model được coi như là Low Level Requirement + Software Architect + Detailed Design + Interface Design + Test Enviroment của bạn.

b. Thay vì viết vài trăm trang giấy viết phần design, interface, ta dùng sơ đồ khối để mô tả mối liên hệ, tương tác giữa các bộ phận.

c. System Engineer có thể simulate cái model để validate system requirement ngay khi nó chỉ là “paperware” thay vì đợi tới gần cuối project. Ta có thể coi đây là Executable Specification. Thay vì đọc vài trăm trang giấy, để hiểu rõ nó làm việc như thế nào, simply hit the play button and watch the animation.

d. Model cũng có thể tổng hợp từ nhiều models khác nhau cho nên ta dùng Simulink Check để verify model của mọi người đều meet modeling standard. Ví dụ như, tên model, tên subsystem, tên signal, layout từ trái sang phải, màu sắc … NASA viết vài trăm modeling rules gọi là NASA Style Guide cho Orion project. Automotive cũng có vài trăm rules cho riêng industry của mình.

e. Khi mổi phần model (subsystem) được làm xong, ta cần phải link nó với requirements trong Simulink requirement để đảm bảo tính liên kết của requirement đó với model. Khi được link thì requirement đó có status là nó đã được implemented. Program manager chỉ cần run model report là biết ngay tiến độ thi công để báo cáo cho khách hàng.

< Nguồn tác giả: Billy Bob >