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!
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.