ความปลอดภัยเชิงฟังก์ชัน (Functional Safety) ช่วยให้มั่นใจได้ว่าระบบสมองกลฝังตัวที่ควบคุมกระบวนการทางกายภาพ เช่น มอเตอร์ วาล์ว เบรก และพวงมาลัย จะเข้าสู่สถานะปลอดภัยเมื่อเกิดความขัดข้องของฮาร์ดแวร์หรือซอฟต์แวร์ เพื่อป้องกันการบาดเจ็บหรือการเสียชีวิต มาตรฐานสากล IEC 61508 เป็นมาตรฐานพื้นฐานสำหรับความปลอดภัยเชิงฟังก์ชันของระบบไฟฟ้าและอิเล็กทรอนิกส์ รวมถึงระบบอิเล็กทรอนิกส์ที่ตั้งโปรแกรมได้ โดยกำหนดระดับความสมบูรณ์ด้านความปลอดภัย (Safety Integrity Levels หรือ SIL) ไว้ 4 ระดับ ตั้งแต่ SIL 1 ถึง SIL 4 ตามข้อกำหนดด้านความเสี่ยงและความน่าจะเป็นของความขัดข้องที่เป็นอันตรายของฟังก์ชันความปลอดภัย

มาตรฐาน ISO 26262 เป็นมาตรฐานความปลอดภัยเชิงฟังก์ชันสำหรับระบบไฟฟ้าและอิเล็กทรอนิกส์ในยานยนต์ ซึ่งพัฒนาต่อยอดจากแนวคิดของ IEC 61508 โดยกำหนดระดับความสมบูรณ์ด้านความปลอดภัยสำหรับยานยนต์ (Automotive Safety Integrity Levels หรือ ASIL) ตั้งแต่ ASIL A ถึง ASIL D โดยพิจารณาจากความรุนแรงของอันตราย (Severity) ความถี่หรือความน่าจะเป็นในการสัมผัสกับสถานการณ์อันตราย (Exposure) และความสามารถในการควบคุมสถานการณ์อันตราย (Controllability)

ระบบที่กำหนดเป้าหมายไว้ที่ SIL 3 ต้องมีความน่าจะเป็นเฉลี่ยของความขัดข้องที่เป็นอันตรายต่อชั่วโมง (Probability of Dangerous Failure per Hour หรือ PFH) ต่ำกว่า 10−710^{-7} สำหรับ ASIL D ซึ่งเป็นระดับสูงสุดของ ISO 26262 นั้น มีข้อกำหนดด้านตัวชี้วัดความผิดพลาดแบบจุดเดียว (Single-Point Fault Metric หรือ SPFM) และตัวชี้วัดความผิดพลาดแฝง (Latent Fault Metric หรือ LFM) ที่เข้มงวด โดยทั่วไปกำหนดค่า SPFM ไม่น้อยกว่า 99% และ LFM ไม่น้อยกว่า 90% สำหรับการจัดประเภทฮาร์ดแวร์ที่เกี่ยวข้อง

สำหรับวิศวกรระบบสมองกลฝังตัว มาตรฐานเหล่านี้กำหนดกระบวนการพัฒนาเฉพาะ เช่น แบบจำลอง V (V-model) วิธีการวิเคราะห์ เช่น FMEA, FTA และ HARA แนวทางการเขียนโค้ด เช่น MISRA C สถาปัตยกรรมฮาร์ดแวร์ที่มีระบบสำรองและกลไกวินิจฉัย รวมถึงกิจกรรมการตรวจสอบ เช่น การวัดความครอบคลุม MC/DC ซึ่งเป็นพื้นฐานสำคัญในการออกแบบ พัฒนา และทดสอบเฟิร์มแวร์ที่มีความสำคัญต่อความปลอดภัย

ระดับ SIL และ ASIL สอดคล้องกับข้อกำหนดในโลกแห่งความเป็นจริงอย่างไร?

มาตรฐาน IEC 61508 กำหนดระดับ SIL ตามเป้าหมายด้านความน่าจะเป็นของความขัดข้องที่เป็นอันตรายต่อชั่วโมง (PFH) สำหรับโหมดการทำงานแบบต่อเนื่องหรือแบบมีความต้องการทำงานความถี่สูง โดยช่วงค่าที่ใช้โดยทั่วไปมีดังนี้: SIL 1 ตั้งแต่ 10−610^{-6} ถึงต่ำกว่า 10−510^{-5}, SIL 2 ตั้งแต่ 10−710^{-7} ถึงต่ำกว่า 10−610^{-6}, SIL 3 ตั้งแต่ 10−810^{-8} ถึงต่ำกว่า 10−710^{-7} และ SIL 4 ตั้งแต่ 10−910^{-9} ถึงต่ำกว่า 10−810^{-8} ทั้งนี้ ข้อกำหนดและช่วงค่าจะแตกต่างกันตามโหมดการทำงานของระบบ

ในทางปฏิบัติ SIL 1 อาจใช้กับฟังก์ชันความปลอดภัยในระบบอุตสาหกรรมที่มีความเสี่ยงค่อนข้างต่ำ เช่น ระบบตรวจวัดและแจ้งเตือนระดับของเหลว ส่วน SIL 2 อาจใช้กับฟังก์ชันควบคุมความปลอดภัยในกระบวนการอุตสาหกรรม เช่น วาล์วปิดฉุกเฉินและระบบจัดการหัวเผา ส่วน SIL 3 ใช้กับฟังก์ชันที่มีความเสี่ยงสูง เช่น ระบบป้องกันในกระบวนการอุตสาหกรรมอันตรายและระบบอาณัติสัญญาณรถไฟ ขณะที่ SIL 4 ใช้กับฟังก์ชันความปลอดภัยที่ต้องการความเข้มงวดสูงมาก เช่น ระบบอาณัติสัญญาณรถไฟบางประเภท

มาตรฐาน ISO 26262 กำหนดระดับ ASIL โดยพิจารณาจากความรุนแรงของอันตราย (S0–S3) ความถี่หรือความน่าจะเป็นในการสัมผัสกับสถานการณ์อันตราย (E0–E4) และความสามารถในการควบคุมสถานการณ์อันตราย (C0–C3) ตัวอย่างเช่น ฟังก์ชันการทำงานของถุงลมนิรภัยบางประเภทอาจได้รับการจัดระดับ ASIL D ขึ้นอยู่กับการวิเคราะห์อันตรายและความเสี่ยง ขณะที่ตัวควบคุมระบบทำความร้อนเบาะอาจจัดอยู่ในระดับ ASIL A หรือ QM (Quality Management) ซึ่งหมายถึงการพัฒนาภายใต้ระบบบริหารคุณภาพโดยไม่ต้องมีข้อกำหนด ASIL เฉพาะ

การแยกส่วนด้านความปลอดภัย (ASIL Decomposition) ช่วยให้สามารถจัดสรรข้อกำหนดด้านความปลอดภัยไปยังองค์ประกอบที่มีความเป็นอิสระต่อกันตามเงื่อนไขที่มาตรฐานกำหนด อย่างไรก็ตาม ไม่สามารถสรุปได้โดยทั่วไปว่าข้อกำหนด ASIL D จะบรรลุได้เพียงแค่ใช้ระบบย่อย ASIL B สองระบบ ต้องพิจารณาระดับ ASIL ที่จัดสรร ความเป็นอิสระขององค์ประกอบ และข้อกำหนดด้านสถาปัตยกรรมที่เกี่ยวข้องด้วย

กระบวนการพัฒนาด้านความปลอดภัยเชิงฟังก์ชันต้องอาศัยกระบวนการแบบใด?

มาตรฐานทั้งสองใช้กระบวนการพัฒนาอย่างเป็นระบบ ซึ่งมักแสดงด้วยแบบจำลอง V (V-model) โดยกำหนดผลงานและหลักฐานที่ต้องจัดทำในแต่ละขั้นตอน ด้านซ้ายของตัว V ครอบคลุมการกำหนดข้อกำหนดและการออกแบบ ตั้งแต่การวิเคราะห์อันตรายและการประเมินความเสี่ยง (HARA) เป้าหมายด้านความปลอดภัย แนวคิดด้านความปลอดภัยเชิงฟังก์ชัน ข้อกำหนดด้านความปลอดภัยทางเทคนิค ไปจนถึงข้อกำหนดด้านฮาร์ดแวร์และซอฟต์แวร์ ส่วนด้านขวาครอบคลุมการตรวจสอบและยืนยันความถูกต้อง เช่น การทดสอบหน่วย การทดสอบการบูรณาการ การทดสอบการบูรณาการฮาร์ดแวร์และซอฟต์แวร์ ตลอดจนการยืนยันความถูกต้องและการตรวจประเมินด้านความปลอดภัย

สำหรับซอฟต์แวร์ IEC 61508 และ ISO 26262 กำหนดแนวทางและวิธีการตามระดับ SIL หรือ ASIL ที่เกี่ยวข้อง โดย ISO 26262 ส่วนที่ 6 ครอบคลุมการพัฒนาซอฟต์แวร์สำหรับระบบยานยนต์ ซึ่งรวมถึงการใช้วิธีการออกแบบและตรวจสอบที่เหมาะสม การเขียนโปรแกรมเชิงป้องกัน (Defensive Programming) เช่น การตรวจสอบความถูกต้องของข้อมูล การตรวจสอบช่วงค่า และการจัดการข้อผิดพลาด ตลอดจนการใช้แนวทาง MISRA C สำหรับซอฟต์แวร์ภาษา C ตามความเหมาะสม

การวัดความครอบคลุมของเงื่อนไขและการตัดสินใจแบบแก้ไข (Modified Condition/Decision Coverage หรือ MC/DC) เป็นวิธีการสำคัญในการทดสอบซอฟต์แวร์ที่มีความสำคัญต่อความปลอดภัย โดยเฉพาะในระดับความเข้มงวดสูง เช่น SIL 3 และ ASIL D ตามข้อกำหนดที่เกี่ยวข้อง ผลงานทั้งหมดต้องได้รับการทบทวน จัดการการกำหนดค่า และตรวจสอบย้อนกลับได้ ตั้งแต่อันตรายและเป้าหมายด้านความปลอดภัยไปจนถึงข้อกำหนด การออกแบบ การนำไปใช้งาน และกรณีทดสอบ

สถาปัตยกรรมฮาร์ดแวร์แบบใดที่รองรับข้อกำหนดด้านความปลอดภัย?

สถาปัตยกรรมความปลอดภัยทางฮาร์ดแวร์สำหรับระดับ SIL/ASIL ต่างๆ:

• ‍ช่องสัญญาณเดี่ยวพร้อมระบบวินิจฉัย (1oo1D): ใช้ช่องสัญญาณประมวลผลเพียงช่องเดียวร่วมกับกลไกตรวจจับความขัดข้อง เช่น การทดสอบตัวเองของ CPU การทดสอบ RAM ด้วยวิธี March การตรวจสอบความถูกต้องของข้อมูลในหน่วยความจำ Flash ด้วย ECC หรือ CRC ตามการออกแบบ ตัวจับเวลาเฝ้าระวัง (Watchdog Timer) และการตรวจสอบความสอดคล้องของข้อมูลจาก ADC สถาปัตยกรรมนี้อาจเหมาะกับการใช้งานที่มีข้อกำหนดด้านความปลอดภัยไม่สูงมาก ทั้งนี้ ต้องประเมินความสามารถในการวินิจฉัยและความเสี่ยงที่เหลืออยู่ก่อนกำหนดระดับ SIL หรือ ASIL‍
• ระบบสองช่องสัญญาณพร้อมการเปรียบเทียบ (1oo2): ใช้ช่องสัญญาณสองช่องเพื่อประมวลผลหรือเฝ้าติดตามการทำงาน โดยเปรียบเทียบผลลัพธ์เพื่อตรวจจับความไม่สอดคล้องกัน หากพบความขัดข้อง ระบบสามารถเข้าสู่สถานะปลอดภัยได้ตามการออกแบบ การใช้ฮาร์ดแวร์หรือซอฟต์แวร์ที่แตกต่างกันอาจช่วยลดความเสี่ยงจากความขัดข้องที่มีสาเหตุร่วมกัน (Common-Cause Failures) แต่ต้องมีหลักฐานสนับสนุนความเป็นอิสระขององค์ประกอบด้วย ทั้งนี้ ไม่สามารถระบุได้ว่าสถาปัตยกรรมนี้จะรองรับ SIL 2–3 หรือ ASIL B–C ได้โดยอัตโนมัติ‍
• ระบบสองช่องสัญญาณพร้อมการวินิจฉัย (1oo2D): เป็นคำเรียกสถาปัตยกรรมที่อาจใช้ในบางบริบท โดยมีช่องสัญญาณสองช่องและกลไกวินิจฉัยความขัดข้อง อย่างไรก็ตาม ความหมายของสัญลักษณ์ 1oo2D และความสามารถด้านความปลอดภัยต้องพิจารณาตามมาตรฐานและสถาปัตยกรรมที่นำมาใช้ ไม่ควรสรุปว่าการมีระบบสำรองและระบบวินิจฉัยจะทำให้ระบบผ่าน SIL 3 หรือ ASIL D ได้โดยอัตโนมัติ‍
• ไมโครคอนโทรลเลอร์สำหรับงานด้านความปลอดภัย (Safety MCUs): ตัวอย่างอุปกรณ์ที่มีคุณสมบัติสนับสนุนการพัฒนาระบบความปลอดภัย ได้แก่ Infineon AURIX TC3xx, TI TMS570, Renesas RH850 และ NXP S32K3 โดยอุปกรณ์บางรุ่นมีคอร์ประมวลผลแบบ Lockstep หน่วยความจำ RAM และ Flash พร้อมระบบตรวจจับและแก้ไขข้อผิดพลาด (ECC) วงจรตรวจสอบสัญญาณนาฬิกาและแรงดันไฟฟ้า ตลอดจนระบบทดสอบตัวเองในตัว (Built-In Self-Test หรือ BIST) คุณสมบัติเหล่านี้ช่วยสนับสนุนการออกแบบระบบที่ต้องการความปลอดภัยระดับสูง แต่การใช้ MCU เพียงอย่างเดียวไม่ได้รับประกันว่าระบบจะผ่านการรับรอง ASIL D หรือมีความครอบคลุมในการวินิจฉัยเกิน 99%

รูปแบบการเขียนเฟิร์มแวร์ที่มีความสำคัญต่อความปลอดภัยสำหรับ IEC 61508 และ ISO 26262

ตัวอย่างโค้ดภาษา C ต่อไปนี้แสดงแนวทางการเขียนโปรแกรมเชิงป้องกันและการตรวจสอบลำดับการทำงาน โดยต้องปรับใช้ให้เหมาะสมกับแพลตฟอร์มและข้อกำหนดด้านความปลอดภัยจริง

/* 1. Defensive programming - range checking */
typedef enum { VALVE_CLOSED = 0, VALVE_OPEN = 1 } valve_state_t;

bool set_valve_position(valve_state_t state) {
 /* ตรวจสอบช่วงค่าของสถานะวาล์ว */
 if (state != VALVE_CLOSED && state != VALVE_OPEN) {
   safety_error_handler(ERR_INVALID_VALVE_STATE);
   return false;
 }

 /* เขียนค่าและอ่านกลับเพื่อตรวจสอบ */
 GPIO_WritePin(VALVE_GPIO, (uint32_t)state);
 uint32_t readback = GPIO_ReadPin(VALVE_GPIO);

 if (readback != (uint32_t)state) {
   safety_error_handler(ERR_VALVE_READBACK_FAIL);
   return false;
 }

 return true;
}

/* 2. Program flow monitoring */
static volatile uint32_t flow_counter = 0;
#define FLOW_CHECKPOINT_INIT    0xA5A5A5A5u
#define FLOW_CHECKPOINT_SENSOR  0x12345678u
#define FLOW_EXPECTED_FINAL     0xB7D9FE1Du

void safety_control_loop(void) {
 flow_counter = FLOW_CHECKPOINT_INIT;
 read_sensors();
 flow_counter ^= FLOW_CHECKPOINT_SENSOR;

 run_control_algo();
 flow_counter ^= FLOW_CHECKPOINT_ALGO;

 set_actuators();
 flow_counter ^= FLOW_CHECKPOINT_OUTPUT;

 if (flow_counter != FLOW_EXPECTED_FINAL) {
   /* หากลำดับการทำงานผิดปกติ ให้เข้าสู่สถานะปลอดภัย */
   emergency_shutdown();
 }
}


การทดสอบซอฟต์แวร์แบบใดบ้างที่จำเป็นสำหรับการรับรองความปลอดภัย?

ข้อกำหนดด้านการทดสอบขึ้นอยู่กับระดับ SIL หรือ ASIL และวิธีการพัฒนาที่เลือกใช้ การทดสอบหน่วย (Unit Testing) เป็นส่วนสำคัญของการยืนยันความถูกต้องของซอฟต์แวร์ ส่วนการทดสอบความครอบคลุมของคำสั่งและสาขา รวมถึง MC/DC จะถูกเลือกใช้ตามระดับความเข้มงวดและข้อกำหนดที่เกี่ยวข้อง โดย MC/DC มักมีความสำคัญเป็นพิเศษสำหรับซอฟต์แวร์ที่มีความสำคัญต่อความปลอดภัยระดับสูง

MC/DC ต้องแสดงให้เห็นว่าเงื่อนไขย่อยแบบบูลีนแต่ละเงื่อนไขสามารถส่งผลต่อผลลัพธ์ของการตัดสินใจได้อย่างเป็นอิสระ การทดสอบนี้จึงเข้มงวดกว่าการตรวจสอบความครอบคลุมของสาขาเพียงอย่างเดียว การทดสอบการบูรณาการต้องตรวจสอบอินเทอร์เฟซระหว่างโมดูลซอฟต์แวร์และระหว่างซอฟต์แวร์กับฮาร์ดแวร์

การทดสอบแบบ Back-to-back ใช้เปรียบเทียบผลลัพธ์ของแบบจำลองอ้างอิง เช่น แบบจำลองใน Simulink กับผลลัพธ์ของโค้ดที่สร้างขึ้นหรือโค้ดที่นำไปใช้งานจริง ส่วนการทดสอบโดยการฉีดข้อผิดพลาด (Fault Injection Testing) ใช้ตรวจสอบว่ากลไกความปลอดภัยสามารถตรวจจับและจัดการข้อผิดพลาดได้อย่างเหมาะสม เช่น ความเสียหายของหน่วยความจำ ความขัดข้องของเซ็นเซอร์ และข้อผิดพลาดในการสื่อสาร

เครื่องมือวิเคราะห์แบบสถิต (Static Analysis Tools) เช่น Polyspace, PC-lint และ Coverity สามารถช่วยตรวจสอบการปฏิบัติตามแนวทางการเขียนโค้ด เช่น MISRA C:2012 และตรวจจับข้อผิดพลาดที่อาจเกิดขึ้นได้โดยไม่ต้องรันโปรแกรม เช่น การหารด้วยศูนย์ บัฟเฟอร์ล้น และการเข้าถึงหน่วยความจำผ่านตัวชี้ที่ไม่ถูกต้อง อย่างไรก็ตาม เครื่องมือแต่ละชนิดมีขอบเขตการตรวจสอบต่างกัน และการใช้เครื่องมือเพียงอย่างเดียวไม่สามารถทดแทนกระบวนการยืนยันความถูกต้องทั้งหมดได้

ประเด็นสำคัญ

IEC 61508 กำหนดระดับ SIL 1–4 ตามข้อกำหนดด้านความเสี่ยงและความน่าจะเป็นของความขัดข้องที่เป็นอันตราย ขณะที่ ISO 26262 กำหนดระดับ ASIL A–D โดยพิจารณาจากความรุนแรงของอันตราย การสัมผัสกับสถานการณ์อันตราย และความสามารถในการควบคุมสถานการณ์ ทั้งสองมาตรฐานเน้นกระบวนการพัฒนาที่เป็นระบบ การวิเคราะห์อันตรายและความขัดข้อง การตรวจสอบย้อนกลับของข้อกำหนด และการยืนยันความถูกต้องของฮาร์ดแวร์และซอฟต์แวร์

แนวทางที่อาจนำมาใช้ ได้แก่ MISRA C การทดสอบความครอบคลุม MC/DC ตามระดับความเข้มงวดที่กำหนด และสถาปัตยกรรมฮาร์ดแวร์ที่มีระบบวินิจฉัย เช่น คอร์แบบ Lockstep และหน่วยความจำ ECC ทั้งนี้ ต้องประเมินความเหมาะสมและหลักฐานประกอบตามข้อกำหนดของมาตรฐาน ไม่ควรถือว่าคุณสมบัติเหล่านี้เพียงอย่างเดียวรับประกันการรับรองความปลอดภัย

เราจะได้รับการรับรอง ISO 26262 ASIL B สำหรับ ECU ยานยนต์ได้อย่างไร?

กรณีศึกษาต่อไปนี้อธิบายแนวทางพัฒนาทางวิศวกรรมสำหรับ ECU ที่ใช้เชื่อมต่อกับเซ็นเซอร์แรงบิดของระบบพวงมาลัยเพาเวอร์ไฟฟ้า (Electric Power Steering หรือ EPS) ภายใต้ข้อกำหนด ASIL B สำหรับซัพพลายเออร์ยานยนต์ระดับ Tier 1 ECU นี้ประมวลผลสัญญาณจากเซ็นเซอร์แรงบิดสองชุดที่ทำงานแยกจากกัน ซึ่งใช้เซ็นเซอร์ GMR ที่ให้สัญญาณแรงดันแอนะล็อก จากนั้นคำนวณแรงบิดช่วยผ่อนแรงในการบังคับเลี้ยวที่ต้องการ และส่งข้อมูลผ่าน CAN FD ไปยังตัวควบคุมมอเตอร์ EPS

ฮาร์ดแวร์ที่ระบุในกรณีศึกษาคือ Infineon AURIX TC375 ซึ่งใช้สถาปัตยกรรมไมโครคอนโทรลเลอร์ตระกูล TriCore และมีคุณสมบัติด้านความปลอดภัยในตัว รวมถึงคอร์แบบ Lockstep ตามการกำหนดค่าที่เกี่ยวข้อง การพัฒนาซอฟต์แวร์อ้างอิงข้อกำหนด ISO 26262 ส่วนที่ 6 และใช้เครื่องมือ PC-lint Plus กับ Polyspace ในการตรวจสอบการปฏิบัติตามแนวทาง MISRA C:2012

ผลการตรวจสอบตามกรณีศึกษาระบุว่า ไม่พบข้อผิดพลาดระดับวิกฤตและระดับบังคับตามเกณฑ์ที่ใช้ และพบข้อผิดพลาดระดับแนะนำให้แก้ไข 12 รายการ การทดสอบหน่วยด้วยเครื่องมือ LDRA รายงานความครอบคลุม MC/DC 98.2% ในโมดูลที่มีความสำคัญต่อความปลอดภัย ส่วนการวิเคราะห์ HARA ระบุเป้าหมายด้านความปลอดภัย 14 ข้อ

แนวคิดด้านความปลอดภัยที่นำมาใช้ประกอบด้วย การตรวจสอบความสอดคล้องของสัญญาณจากเซ็นเซอร์แรงบิด โดยกำหนดให้สัญญาณต้องสอดคล้องกันภายในค่าความคลาดเคลื่อน 3% มิฉะนั้นจะสั่งให้ระบบเข้าสู่สถานะปลอดภัย การตรวจสอบตัวนับลำดับข้อความและ CRC สำหรับการสื่อสาร CAN FD ตลอดจนการตรวจสอบลำดับการทำงานของโปรแกรมและการใช้ BIST ของไมโครคอนโทรลเลอร์ ทั้งนี้ การใช้ SecOC ต้องพิจารณาให้สอดคล้องกับการกำหนดค่าและข้อกำหนดด้านความปลอดภัยของการสื่อสาร

ตามข้อมูลในกรณีศึกษานี้ TÜV Rheinland ใช้เวลาประเมิน 6 เดือน ซึ่งประกอบด้วยการตรวจสอบเอกสาร 3 รอบและการตรวจประเมิน ณ สถานที่ 2 ครั้ง กระบวนการพัฒนาและเตรียมการรับรองใช้เวลารวม 14 เดือน และมีการระบุค่าธรรมเนียมการประเมิน 180,000 ดอลลาร์สหรัฐ ตัวเลขเหล่านี้เป็นข้อมูลเฉพาะของกรณีศึกษาที่ให้มา ไม่ใช่ระยะเวลาและค่าใช้จ่ายมาตรฐานสำหรับโครงการรับรอง ISO 26262 ทุกโครงการ

ข้อผิดพลาดด้านความปลอดภัยเชิงฟังก์ชันที่พบบ่อยที่สุดมีอะไรบ้าง?

ข้อผิดพลาดที่มีค่าใช้จ่ายสูงประการหนึ่งคือการมองความปลอดภัยเชิงฟังก์ชันเป็นเพียงงานจัดทำเอกสาร แทนที่จะเป็นกระบวนการทางวิศวกรรมที่ต้องขับเคลื่อนการพัฒนาตั้งแต่ต้น ทีมที่จัดทำเอกสารความปลอดภัยหลังจากการพัฒนาเสร็จสิ้นแล้ว อาจพบข้อบกพร่องในสถาปัตยกรรมที่จำเป็นต้องแก้ไขด้วยการออกแบบใหม่ซึ่งมีค่าใช้จ่ายสูง

ควรผสานการวิเคราะห์ความปลอดภัยเข้ากับขั้นตอนการกำหนดแนวคิด โดยดำเนินการ HARA ก่อนสรุปสถาปัตยกรรมระบบ กำหนดข้อกำหนดด้านความปลอดภัยก่อนออกแบบซอฟต์แวร์ และตรวจสอบย้อนกลับข้อกำหนดแต่ละข้อไปจนถึงการนำไปใช้งานและกรณีทดสอบ

อีกประเด็นหนึ่งคือความสามารถในการวินิจฉัยความขัดข้องของฮาร์ดแวร์ที่ไม่เพียงพอ สำหรับ ASIL D จะมีข้อกำหนดเกี่ยวกับ SPFM และ LFM ที่เข้มงวด โดยทั่วไปค่า SPFM ต้องไม่น้อยกว่า 99% และ LFM ต้องไม่น้อยกว่า 90% สำหรับการจัดประเภทฮาร์ดแวร์ที่เกี่ยวข้อง การบรรลุเป้าหมายเหล่านี้ต้องอาศัยการออกแบบและการวิเคราะห์ที่เหมาะสม เช่น การใช้คอร์แบบ Lockstep หน่วยความจำ ECC และการตรวจสอบการทำงานของอุปกรณ์ต่อพ่วง การเลือก MCU ที่มีคุณสมบัติสนับสนุนด้านความปลอดภัย เช่น Infineon AURIX, TI TMS570 หรือ Renesas RH850 อาจช่วยลดภาระการออกแบบ แต่ไม่ได้ทดแทนการวิเคราะห์และการประเมินระดับระบบ

ประการสุดท้าย การประเมินเวลาและทรัพยากรสำหรับจัดทำเอกสารต่ำเกินไปอาจส่งผลต่อโครงการได้ การจัดทำข้อกำหนดด้านความปลอดภัย รายงานการวิเคราะห์ หลักฐานการทดสอบ และเอกสารการตรวจสอบย้อนกลับต้องใช้ทรัพยากรอย่างมีนัยสำคัญ อย่างไรก็ตาม จำนวนเอกสารและสัดส่วนงบประมาณที่ต้องใช้ขึ้นอยู่กับขนาด ความซับซ้อน และระดับความปลอดภัยของโครงการ จึงไม่ควรกำหนดจำนวนเอกสารหรืองบประมาณเป็นค่าตายตัวสำหรับทุกโครงการ

มาตรฐานความปลอดภัยมีผลบังคับใช้กับระบบสมองกลฝังตัวที่ใช้ AI อย่างไร?

แบบจำลองการเรียนรู้ของเครื่อง (Machine Learning หรือ ML) ในระบบที่มีความสำคัญต่อความปลอดภัยสร้างความท้าทายให้กับแนวทางด้านความปลอดภัยเชิงฟังก์ชันแบบดั้งเดิม เนื่องจากพฤติกรรมของแบบจำลอง ML อาจไม่สามารถอธิบายหรือคาดการณ์ได้อย่างครบถ้วนสำหรับอินพุตทุกประเภท และไม่สามารถรับประกันความถูกต้องของผลลัพธ์สำหรับทุกสถานการณ์ได้

ในอุตสาหกรรมยานยนต์ ISO 21448 หรือ SOTIF (Safety of the Intended Functionality) มุ่งเน้นการจัดการอันตรายที่เกิดจากข้อจำกัดของฟังก์ชันที่ตั้งใจให้ระบบทำงาน รวมถึงข้อจำกัดด้านประสิทธิภาพของระบบรับรู้ที่อาจใช้ AI หรือ ML แนวทางที่เกี่ยวข้องประกอบด้วยการตรวจสอบความถูกต้องกับชุดสถานการณ์ที่ครอบคลุม รวมถึงกรณีขอบเขตและสถานการณ์ที่ยากต่อการรับรู้ การระบุสถานการณ์ที่อาจทำให้ระบบทำงานผิดพลาด และการพิจารณามาตรการลดความเสี่ยงที่เหมาะสม เช่น การตรวจสอบความสมเหตุสมผลของผลลัพธ์ การใช้ระบบสำรอง และการเข้าสู่สถานะปลอดภัยเมื่อพบความผิดปกติ

ตัวอย่างเงื่อนไขที่อาจทำให้แบบจำลอง ML ทำงานผิดพลาด ได้แก่ สภาพแสงผิดปกติ วัตถุถูกบดบังบางส่วน และประสิทธิภาพของเซ็นเซอร์ลดลง สำหรับการใช้งานในอุตสาหกรรม ต้องเลือกมาตรฐานและแนวทางที่เกี่ยวข้องกับประเภทของระบบและระดับความเสี่ยง โดยควรตรวจสอบชื่อและขอบเขตของมาตรฐานเฉพาะที่ใช้กับ ML ในระบบที่เกี่ยวข้องกับความปลอดภัยก่อนอ้างอิง

ในทางปฏิบัติ สถาปัตยกรรมระบบอาจใช้ ML สำหรับการรับรู้หรือเสนอคำแนะนำ และใช้กลไกตรวจสอบแยกต่างหากเพื่อประเมินความสมเหตุสมผลของผลลัพธ์ รวมถึงสั่งให้ระบบเข้าสู่สถานะปลอดภัยเมื่อจำเป็น อย่างไรก็ตาม กลไกตรวจสอบดังกล่าวต้องได้รับการออกแบบ วิเคราะห์ และยืนยันความถูกต้องตามข้อกำหนดด้านความปลอดภัยที่เกี่ยวข้อง การใช้สถาปัตยกรรมลักษณะนี้จึงช่วยจัดการความเสี่ยงจากการใช้ ML ได้ แต่ไม่ได้รับประกันการรับรองความปลอดภัยโดยอัตโนมัติ