Model-Based Software Development เท่าที่รู้

ถ้าหากเราพูดถึงการสร้าง Model อะไรสักอย่าง คนในวงการเทคสมัยนี้อาจจะนึกถึงโมเดลทางคณิตศาสตร์บ้าง การเทรนโมเดลในแมชชีนเลิร์นนิ่งบ้าง น้อยคนมาก ๆ ที่จะนึกถึง Model-Based Design (MBD) ที่เราใช้กันในอุตสาหกรรมซอฟท์แวร์รถยนต์ บางคนอาจจะไม่เคยได้ยินมันมาก่อนด้วยซ้ำ

ส่วนตัวเคยลองเซิร์ชหาคอนเท้นท์เกี่ยวกับเรื่องนี้ในเวอร์ชั่นภาษาไทยดูแต่แทบไม่เจอเลย ก็เอาเป็นว่า.. ไม่เจอก็ไม่เจอ ไม่เป็นไร เขียนขึ้นมาเองเลยแล้วกัน!
นั่นเลยเป็นที่มาของเอนทรี่นี้ “Model-Based Design (MBD) สำหรับ Software Development” แบบง่าย ๆ เท่าที่รู้ค่ะ (เน้น ๆ เลย เท่าที่รู้)

Model-Based Design (MBD) คืออะไร?

พูดง่าย ๆ เลยคือการที่เราเอาโลจิกบล็อก*มาต่อกันให้เกิดเป็นการทำงานของระบบระบบหนึ่งขึ้นมา (จะเรียกว่าระบบ, คอนโทรลเลอร์, ซอฟท์แวร์หรืออะไรก็ตามแต่) จะมองว่าเหมือนเขียนโปรแกรมด้วยโค้ดดิ้งก็ได้ เพียงแต่เราเปลี่ยนจากการเขียนโค้ดด้วยตัวอักษรทีละบรรทัด เป็นการลากกล่อง AND, OR มาต่อกันให้เกิดเป็นโปรแกรมขึ้นมาแทนแล้วค่อยทำการ generate source code จากโมเดลอีกที

ตัวอย่างการแปลงโฟลวชาร์ทเป็นโมเดล

*จริง ๆ แล้วบล็อกที่เราใช้ได้มีเยอะกว่าโลจิกบล็อกมาก จะมีทั้ง integral บล็อก differential บล็อกและบล็อกทางคณิตศาสตร์อื่น ๆ แต่ในที่นี้ขออนุญาต simplify เพื่อความง่าย

ทำไมต้องใช้ Model-Based Design?

ในวงการ embedded software/system นิยมใช้ภาษา C กันมากเนื่องจากมันตอบโจทย์หลาย ๆ อย่างทั้ง performance (ที่ allow optimization) ทั้งการทำ bit manipulation รวมถึง portability ซึ่งซอฟท์แวร์ที่เราใช้กันในรถก็เป็นหนึ่งในนั้นและ characteristic หลักของซอฟท์แวร์ในวงการนี้คือถ้าไม่จำเป็นเค้าไม่ค่อยแก้กันหรอก ก็จะพอร์ทซอฟท์แวร์ของเดิมมาเป็นเบสแล้วค่อยบิ้วด์ฟังก์ชั่นใหม่ต่อยอดขึ้นไป ก็จะมีสารพัด legacy code ที่มันโคตรจะ legacy จริง ๆ ให้คุณได้เห็น (เวลาเทสต์ของใหม่ที criteria มันเยอะ ไม่ใช่แค่เทสต์ในคอมพ์แล้วจะจบ ต้องมีไปเทสต์บนรถจริงด้วย ให้การันตีว่ามันผ่านมาตรฐานต่าง ๆ)

แล้วสรุปทำไมต้องใช้ Model-Based Design? ต่อเนื่องจากเพนพ้อยท์เมื่อกี้แหละโดยเฉพาะเมื่อเรา dev ด้วยภาษา C ด้วยแล้ว ต้องบอกว่า readability ของโค้ดมันต่ำมากแล้วยิ่งเป็นซอฟท์แวร์ที่ใช้ในรถที่มีกันกี่โดเมนกี่ฟังก์ชั่นรวมกันมาเป็นโค้ดกี่ล้านบรรทัดก็ไม่รู้ ด้วยเหตุนั้นเวลาจะแก้ไขหรือดีบั๊กอะไรแต่ละทีมันใช้เวลานาน เซนส์ของ OOP ก็ไม่มี maintenance ทีหรือแค่อยากพอร์ทบางฟังก์ชั่นจากโปรเจ็คหนึ่งไปอีกโปรเจ็คหนึ่งก็ลำบาก ซึ่งการเอา Model-Based มาช่วยมันตอบโจทย์อะไรพวกนี้ได้

1. Readability

การที่ซอฟท์แวร์เปลี่ยนมาอยู่ในรูปของโมเดลทำให้เรามองเห็น data flow ได้ชัดเจนมากขึ้น ไม่ว่าจะเป็น input ที่เอามาใช้ judgment ใน function ของเรา, output signal ที่จะส่งต่อให้โดเมนอื่นใช้ในการคอนโทรล

เช่นตัวอย่างด้านล่าง;
สมมติว่าเราอยากทำระบบรดน้ำต้นไม้สวนในบ้านเราซึ่งมีฟังก์ชั่นหลัก ๆ อยู่ 4 อัน

#1 วัดอุณหภูมิ
#2 วัดความชื้น
#3 วัดมุมปัจจุบันที่เครื่องฉีดน้ำหันอยู
#4 ตัดสินใจ movement

จะเห็นได้ว่าถ้าเขียนเป็นโค้ดเองโดยตรง เราจะยังไม่สามารถ visualize dataflow และลำดับขั้นตอนในการตัดสินใจได้ในทันที แต่พอทำเป็น model-based แล้วเราจะพอเห็นภาพได้เร็วขึ้นว่าการตัดสินใจของฟังก์ชั่นไหนอยู่ตรงไหน ฟังก์ชั่นอะไรส่งสัญญาณไปใช้ต่อที่ฟังก์ชั่นอะไร เป็นต้น
ซึ่งต้องลองนึกภาพต่อไปว่าซอฟท์แวร์ที่ใช้ในรถจริง ๆ นั้นซับซ้อนกว่าในตัวอย่างนี้มาก การที่เราสามารถ visualize ระบบของเราได้เร็วขึ้นหรือดีขึ้นเท่าไหร่ ก็จะยิ่งง่ายต่อการทำความเข้าใจและประหยัดเวลาในการทำงานให้เรามากขึ้นเท่านั้น

ขออภัยสำหรับลายมือ5555555555

2. Easy for maintenance and create based common module

ให้ลองนึกภาพว่าแต่ละฟังก์ชั่นที่เราสร้างขึ้นมาก็เหมือนเป็นจิ๊กซอว์ชิ้นนึง ถ้าเราแบ่งฟังก์ชั่นการทำงานของมันได้ดี เวลาเรามีโปรเจ็ครถใหม่เราจะสามารถเลือกแต่ละโมดูลที่เราต้องการมาประกอบกันได้เลยโดยที่เราอาจจะไม่ต้องทำดีเทลเทสต์ภายในแต่ละโมดูลใหม่แล้วก็ได้ (เนื่องจากเราต้องมีทำดีเทล/ยูนิตเทสต์ไปแล้วตอนที่สร้างแต่ละโมดูลนั้นขึ้นมา) ก็จะเหลือเพียงต้องทำ system test/integration test เพื่อทดสอบระบบหลังจากที่ประกอบทุกอย่างเข้าด้วยกันแล้วเฉย ๆ ซึ่งจะประหยัดเวลาเราไปได้มาก

3. Able to simulate control behavior

อีกคีย์สำคัญก็คือเราสามารถทำ simulation เพื่อดูลักษณะสัญญาณ output ของโมเดลเราได้ พูดอย่างนี้แล้วอาจจะงงนิดหน่อยว่าหน้าตามันออกมาประมาณไหน เนื่องจากว่าซอฟท์แวร์ที่เราใช้กันในรถ หรือ embedded software เนี่ย เราสร้างมันขึ้นมาเพื่อ finally ควบคุม actual hardware อะไรซักอย่าง อย่างเช่นควบคุมจังหวะการฉีดน้ำมัน หัวเทียนจุดระเบิด การเปิดปิดของปีกผีเสื้อเพื่อควบคุมปริมาณอากาศที่เข้ามาในลูกสูบ เพราะงั้นสัญญาณที่เราจะเห็นในโมเดลเนี่ยจะเป็น time series อยู่ละ แต่จะเป็น voltage, current ความดันหรืออะไรก็ว่ากันไปตามแต่ละเซ็นเซอร์ ซึ่งรูปแบบมันก็จะใกล้เคียงกับของจริงมาก ทำให้เราสามารถทำการเทสต์ซอฟท์แวร์ของเราเบื้องต้นได้โดยที่ยังดู make sense ในแง่ของ functionality หากจะเอาไปคุยกันต่อกับคนที่ออก requirement มาหากอยากเสนอแนะหรือปรับแก้อะไรกัน

ลองไปดูที่บทความนี้เพิ่มเติมได้ ผล simulation ของเราก็จะประมาณผลเทสต์ที่เค้าแปะไว้ใน article เลย: Component-in-the-Loop Testing of Automotive Powertrains Featuring All-Wheel-Drive

อย่างไรก็ตาม มีข้อดีก็ต้องมีข้อเสียหรือในที่นี้จะเรียกว่าข้อจำกัดก็ได้ ถึงแม้เราจะบอกว่าเราสามารถสร้างซอฟท์แวร์ของเราด้วยวิธี Model-Based นี้ได้แล้ว แต่ซอฟท์แวร์ที่เอามาสร้างในรูปแบบนี้ได้ส่วนใหญ่เป็น higher level ที่เราเรียกว่าอยู่ในส่วนของ application พอเราจะเริ่มเอาสัญญาณที่เราตัดสินใจได้ในชั้น application นี้ไปสั่งการ hardware ต่อ ยังไงก็ต้องมีส่วน basic software ที่เป็นการโค้ดดิ้งจริง ๆ มาซัพพอร์ทอีกทีอยู่ดี ซึ่งในวงการรถก็จะมี standard architecture ดัง ๆ ของเค้าที่เรียกกันว่า AUTOSAR

Automotive Software Architecture

AUTOSAR หรือ Automotive Open System Architecture ซึ่งก็มีหลายแบบมาก ในที่นี้เราจะยกมาตัวอย่างนึงซึ่งก็คือเวอร์ชั่น Classic ถ้ามองคร่าว ๆ จากรูปด้านล่างจะเห็นได้ว่าเค้าจะแบ่งออกเป็น 3 layers ใหญ่ ๆ ที่จะรันอยู่เหนือ Microcontroller ของเรา

1. Application Layer (APP)
2. Runtime Environment (RTE)
3. Basic Software (BSW)

reference from: https://www.autosar.org/standards/classic-platform

จากที่บอกว่า Model-Based ซอฟท์แวร์ของเราอยู่บน APP จะเห็นได้ว่า APP นี่คือ High Level มาก ๆ (มากที่สุดใน architecture นี้แล้ว) จะเป็นตัวที่ hardware independent ที่สุด เพราะฉะนั้นเวลาเราได้ final output ที่จะนำไปใช้ control ตัว actual hardware แล้วจึงต้องผ่านอีกหลายชั้นโดยมี RTE เป็นชั้น interface เชื่อมระหว่าง APP กับ BSW อีกทีซึ่งต้องสร้างมือขึ้นมาทั้งหมดด้วย source code

V-model software development

คุณมี agile ของคุณ ผมก็มี V-model ของผมก็แล้วกัน.. ผ่าม..

ทุกคนน่าจะคุ้นเคยกันดีกับ agile development กันอยู่แล้ว และเอาจริง ๆ ไม่ได้จะบอกว่าบริษัทรถหรือบริษัทที่ทำเกี่ยวกับ embedded จะไม่ใช้ agile ที่ ๆ ใช้ agile ก็มี ที่ ๆ กำลังปรับใช้อยู่ก็มี แล้วในขณะที่กำลังปรับอยู่นี้เค้าใช้อะไรกัน? เลยอยากจะมาพูดถึงหนึ่งในนั้นแทนว่าเค้ามีใช้อะไรบ้าง

reference from: https://www.javatpoint.com/software-engineering-v-model

คอนเซ็ปท์ของมันก็คือทุกขั้นตอนหรือทุกโปรดักที่เรา dev ขึ้นมาได้ จะต้องมีหนึ่งเสต็ปการเทสต์ที่เข้าคู่กันที่สามารถ validate ได้ว่า deliverables จากเสต็ปนั้น ๆ ที่เราสร้างขึ้นมานั้นเชื่อถือได้ อย่างเช่น

1. System Requirement <-> System Integration Testing
   เราจะยืนยันได้ว่าเรา extract system requirement มาถูกต้อง ก็ต้องมีการเทสต์ในระดับ system integration ที่เห็นการทำงานของทั้งระบบที่เกี่ยวข้องแล้วเท่านั้น
2. Low level design <-> Unit Testing
   ในภาพใหญ่เรารู้แล้วว่าระบบของเราต้องการอะไร ในภาพเล็กของ low level design นี้ก็จะเริ่มละเอียดลงมาเลยในระดับโลจิก ซึ่งบางทีเราก็อาจจะไม่ได้มองเรื่องความเข้าใจได้ของฟังก์ชั่นนั้น ๆ ละ สนใจแค่สัญญาณมันออนออฟตามที่เราคิดไว้มั้ย เมื่อป้อนเทสแพทเทิร์นนี้เข้าไป ตอนเทสต์ก็เลยจะอยู่ในเลเวลนี้เท่า ๆ กัน

ส่งท้าย

ขอบคุณทุกคนที่อ่านกันมาจนจบ555555 หวังว่าทุกคนจะรู้จัก MBD กันขึ้นมาบ้างไม่มากก็น้อย เนื้อหาในส่วนนี้ตั้งใจไม่ให้ดีเทลมาก (หวังว่า) แค่อยากให้พอเห็นภาพรวมเฉย ๆ เพราะฉะนั้นหากมีเนื้อหาจุดไหน over-simplify ไปบ้าง หรือไม่ accurate บ้างต้องขอโทษด้วย สามารถทิ้งคอมเม้นเพิ่มเติมไว้ได้ตามอัธยาศัยเลยเด้อ