Quản lý kiểm soát phần mềm hàng không

Quản lý kiểm soát phần mềm hàng không

Phần mềm máy bay không nhìn thấy, không sờ được, nhưng phải được đối xử như mọi chi tiết máy bay khác. Một thay đổi phần mềm chưa được phê duyệt có thể gây mất máy bay. Module này trả lời bốn câu hỏi: phần mềm hỏng nặng đến đâu thì được coi là nguy hiểm (5 mức A đến E), chuẩn DO-178B/C bắt buộc những tài liệu và truy vết nào, phần mềm và dữ liệu được nạp lên máy bay ra sao (FLS, LSAP, UMS, OSS, DFLD), và làm sao biết tệp nạp không bị hỏng (checksum, CRC), kèm hai demo chạy trực tiếp.

Tooley ch.13 (tr.207-217) · Bài giảng EASA Part-66 Module 5.13 (6 trang) · Floyd ch.2 mục 2-12 và ch.11 mục 11-11

Phần mềm là một bộ phận máy bay

Theo Tooley (ch.13), phần mềm gồm mã thực thi (chương trình), dữ liệu mà chương trình dùng và cả hệ điều hành nhúng. Tất cả đều cần nâng cấp định kỳ và sửa lỗi phát sinh trong khai thác. Hậu quả hỏng phần mềm trải từ không đáng kể đến thảm hoạ (hỏng hệ avionics lớn, lỗi động cơ).

Chỉ thị khả phi đòi sửa phần mềm: ví dụ thực

Hình 13.1 của Tooley trích một Airworthiness Directive (ATA 73, nhiên liệu và điều khiển, sửa phần mềm EEC). Đã có sáu sự kiện trong khai thác: mất hiển thị thông số động cơ ở buồng lái kèm đóng băng cài đặt công suất của động cơ đó. Điều tra tìm ra nguyên nhân là lỗi phần mềm động cơ. Đánh giá an toàn kết luận có thể gây lực đẩy bất đối xứng nguy hiểm nếu xảy ra lúc chạy đà cất cánh và phi công cố hủy cất cánh. Chỉ thị yêu cầu đưa vào phần mềm động cơ bản sửa.

Năm mức phần mềm A đến E

Ví dụ ứng dụng theo mức (Tooley Bảng 13.2)

Chứng nhận: phần mềm, phần cứng và an toàn hệ thống

Hình 13.2 của Tooley cho thấy vòng đời phần cứng và phần mềm gắn chặt với nhau: đổi cấu hình phần cứng luôn kéo theo đổi cấu hình phần mềm. Quy trình đánh giá an toàn (SAP, AMC 25.1309 và ARP 4761) chạy song song với quy trình phát triển hệ thống (ARP 4754); từ đó tách thành phát triển phần cứng (DO-254) và phần mềm (DO-178B).

Chứng nhận ban đầu yêu cầu tổ chức thiết kế (DO) chứng minh phần mềm đã được thiết kế, thử nghiệm và tích hợp với phần cứng theo DO-178B/ED-12B. Một kế hoạch quản lý cấu hình phần mềm (CMP) phải có hiệu lực suốt đời thiết bị.

Ai được sửa phần mềm sau khi chứng nhận?

Thay đổi sau chứng nhận với thiết bị ở mức A, B, C (thảm hoạ, nguy hiểm, đáng kể) không được thực hiện nếu chưa được DO phê duyệt. Vì vậy mọi nâng cấp và sửa đổi phần mềm chịu cùng thủ tục duyệt như sửa phần cứng. Mọi sửa đổi phải được nhận dạng và kiểm soát theo CMP; hướng dẫn có trong DO-178B/ED-12B và DO-178C/ED-12C (2011).

DO-178B/ED-12B: chuẩn và tài liệu bắt buộc

"Software Considerations in Airborne Systems and Equipment Certification" do RTCA công bố năm 1992 (DO-178B) và EUROCAE (ED-12B). FAA và EASA dùng nó làm hướng dẫn chứng nhận để xét phần mềm có chạy tin cậy trên hệ thống máy bay không. Chuẩn đặt ra mức bảo đảm thiết kế dựa trên quy trình đánh giá an toàn và phân tích hiểm hoạ, xét hậu quả của một tình trạng hỏng trong từng hệ thống.

Ngoài mã: những tài liệu phải có

Ngoài mã nguồn và mã đối tượng thực thi, chuẩn đòi hỏi tài liệu và sản phẩm vòng đời (câu hỏi 13-1): kế hoạch chứng nhận khả phi, kế hoạch bảo đảm chất lượng phần mềm, kế hoạch quản lý cấu hình phần mềm, quy trình kiểm soát cấu hình, chuẩn mã, chuẩn thiết kế, chuẩn yêu cầu, kế hoạch phát triển, kế hoạch kiểm chứng, tài liệu thiết kế, tài liệu yêu cầu, truy vết, test case và test procedure, kết quả kiểm chứng, hồ sơ bảo đảm chất lượng, hồ sơ quản lý cấu hình, báo cáo sự cố và bản tóm tắt thành tựu phần mềm.

Mức A cho điều khiển bay và dẫn đường; ARINC 653

Điều khiển bay và dẫn đường là quan trọng cho chuyến bay nên cần chứng nhận Level A: hỏng có thể gây nhiều thương vong và mất máy bay. Hệ giải trí cabin ở đầu kia của phổ (Level E), trừ việc phi hành đoàn phải có thể ghi đè khi phát thanh. Thông thường các mức khác nhau không chạy trên cùng một bộ xử lý, trừ khi dùng sơ đồ phân vùng phần mềm được duyệt như ARINC 653.

ARINC 653 (Avionics Application Standard Software Interface) là đặc tả phân vùng không gian và thời gian trong hệ điều hành thời gian thực, cho một bộ xử lý chứa nhiều ứng dụng mức khác nhau. Dùng trong hệ IMA, nó cô lập chức năng quan trọng khỏi chức năng không quan trọng để một ứng dụng hỏng không kéo sập cả hệ IMA.

DO-178C và các phụ lục

Khi DO-178B ra đời, phần lớn phần mềm viết tay. Về sau sinh mã tự động từ mô hình phổ biến, nên cần làm rõ ranh giới yêu cầu hệ thống cấp cao với yêu cầu phần mềm cấp thấp, và cần cách kiểm chứng phần mềm dựa trên mô hình (mô phỏng hoặc phương pháp hình thức có thể thay một phần thử nghiệm không). Vì vậy DO-178C ra đời năm 2011. Tháng 7 năm 2013 FAA ban hành AC 20-115C công nhận nó.

Truy vết yêu cầu theo mức (Hình 13-1)

Hình 13-1 vẽ truy vết bắt buộc giữa các sản phẩm chứng nhận theo DO-178C. Đỏ: chỉ phần mềm mức A. Tím: mức A, B, C. Xanh: mức A đến D. Mức E: không cần truy vết vì không quan trọng. Mã đối tượng thực thi mức A phải "bền vững" (robust) với yêu cầu phần mềm, tức đáp ứng đúng với đầu vào và điều kiện bất thường.

Demo: mỗi mức DAL đòi những trace nào?

Chọn một mức trong ô bên dưới trang (Demo 2) để xem xác suất cho phép, ứng dụng điển hình và các trace bắt buộc. Gợi ý thử: so mức A với mức B để thấy đúng hai trace đỏ khác biệt, rồi so mức B với mức C để thấy chúng cùng một tập trace.

Quy tắc rút ra từ hình 13-1: số trace bắt buộc tăng khi mức nghiêm trọng tăng: D (xanh) nhỏ nhất, B và C (xanh và tím) bằng nhau, A (đỏ, tím, xanh) lớn nhất.

Phần mềm nạp được tại hiện trường (FLS)

FLS là mã thực thi nạp vào máy tính khi đang lắp trên máy bay, do thợ cơ khí/kỹ thuật viên nạp theo quy trình trong sổ tay bảo dưỡng. Ba loại chính:

• LSAP (loadable software aircraft part): phần mềm để đáp ứng yêu cầu khả phi hay vận hành; không thuộc thiết kế được duyệt nên là một bộ phận máy bay cần hồ sơ phát hành chính thức. Ví dụ: EEC, DFDAU, ECU của APU, máy tính dẫn hướng bay (FGC).
• UMS (user modifiable software): do chủ sở hữu chứng chỉ loại tuyên bố là cho phép sửa trong ràng buộc chứng nhận; nhà khai thác thường tự nâng cấp. Ví dụ: ACMS, IFE.
• OSS (option selectable software): các thành phần đã duyệt, nhà khai thác kích hoạt trong biên giới do chủ chứng chỉ quy định. Ví dụ: bộ IMA.

Dữ liệu nạp được (DFLD) và vì sao phải đối xử như mã

DFLD là dữ liệu nạp được vào cơ sở dữ liệu của phần cứng đích. Bản thân cơ sở dữ liệu là mục nhúng nằm trong phần cứng và không nạp được; việc "nạp" chỉ là ghi dữ liệu mới hoặc ghi đè dữ liệu cũ từ tệp. Dạng dữ liệu có thể là nhị phân tự nhiên (gọn nhất nhưng người không đọc được), BCD hoặc hex (dễ đọc hơn).

Cập nhật cơ sở dữ liệu thường ảnh hưởng hiệu năng máy bay; dữ liệu sai hoặc hỏng có thể gây hoạt động thất thường hoặc vượt giới hạn. Vì thế DFLD cần số hiệu duy nhất và hồ sơ phát hành riêng như mã LSAP. Ví dụ phần cứng: FMC, TAWS, IMA.

Phân phối và phát hành: Form 1, Certificate of Conformity

Ba cách phân phối: phương tiện lưu trữ (đĩa mềm, thẻ PCMCIA, CD-ROM, mô-đun thay thế OBRM), truyền điện tử (laptop, máy cầm tay hoặc bộ nạp di động qua liên kết nối tiếp hoặc bus tạm), phân phối điện tử (không qua phương tiện trung gian).

Sổ đăng ký và quy tắc cách ly

Nhà khai thác phải giữ một sổ đăng ký ghi: phiên bản FLS/DFLD hiện lắp; máy bay nào có; áp dụng cho hệ thống nào; chức năng; nơi lưu và dạng phương tiện, người chịu trách nhiệm và người được truy cập; ai quyết định cần nâng cấp và duyệt; hồ sơ mọi bản sao truy được về nguồn gốc.

Quy trình nạp phần mềm cho EEC bằng PDL

1. Chắc chắn nguồn điện EEC tắt.
2. Nối một đầu cáp PDL vào bộ nạp.
3. Rút đầu nối điện khỏi EEC.
4. Nối đầu kia của cáp PDL vào EEC.
5. Cấp nguồn 28 V DC cho cáp bộ nạp: nâu (+), đen (−), vỏ bọc (đất khung).
6. Nạp: đúng đĩa cho kênh A và B (NVM và chương trình vận hành); bật 28 V DC cho bộ nạp; bật 115 V AC (400 Hz) cho EEC; cùng phiên bản cho động cơ trái và phải; đĩa không khoá ghi; cho đĩa vào trong 5 phút; PDL tự nạp, mất khoảng 12 đến 16 phút, hiện LOAD COMPLETE; nếu lỗi, đèn lỗi truyền sáng, kiểm tra cáp, tắt nguồn và thử lại, tối đa ba lần.
7. Cắt mọi nguồn khỏi EEC và bộ nạp.
8. Tháo bộ nạp, nối lại cáp EEC.
9. Chạy chương trình kiểm tra bộ nhớ: PASS cho số hiệu EEC và checksum là đạt; FAIL thường do số hiệu phần cứng không khớp số hiệu phần mềm.
10. Ghi phiên bản phần mềm, số Service Bulletin và ngày lên nhãn kim loại của EEC.

Checksum và CRC: hai cách phát hiện tệp hỏng

Checksum: cộng giá trị các byte (hoặc từ) liên tiếp rồi gắn kết quả vào tệp. Khi chuẩn bị nạp, tính lại và so sánh; khác nhau thì không dùng tệp.

CRC: chia các khối nhị phân liên tiếp cho một số định trước; phần dư gắn vào tệp thành các chữ số kiểm tra. Kiểm tra lại: nếu chia hết (dư bằng 0) thì coi như không có lỗi.

Tooley: cả hai chỉ cho biết tệp đã hỏng, nhưng không cái nào tuyệt đối an toàn.

Hãy thử Demo 1 ở cuối trang: bấm "Đổi chỗ 2 byte" và "Hai lỗi triệt tiêu nhau" để thấy chính xác vì sao.

Floyd: parity, CRC và checksum ROM

Parity (Floyd 2-12, tr.110): bit chẵn lẻ làm tổng số bit 1 luôn chẵn hoặc luôn lẻ; phát hiện 1 lỗi bit (hoặc số lẻ lỗi), không phát hiện hai lỗi trong một nhóm. ARINC 429 (Module 05) dùng parity lẻ.

CRC (Floyd 2-12, tr.111 đến 114): bảy bước. Ví dụ 2-41: D = 11010011, G = 1010. Thêm 4 số 0 được 110100110000; chia modulo-2 cho 1010 được phần dư 0100; mã truyền là 110100110100 và phép chia lại cho phần dư 0.

Checksum ROM (Floyd 11-11): checksum là tổng XOR từng cột bit, bỏ bit nhớ; luồng kiểm tra trong Hình 11-75. Bài 37 chương 11 (đã có ở Module 04) hỏi nội dung ROM có đúng không.

Tổng kết: chuỗi kiểm soát từ yêu cầu đến máy bay

1. Phân loại hậu quả hỏng: mức A đến E.
2. Chuẩn DO-178B/C: tài liệu và truy vết theo mức.
3. CMP: nhận dạng và kiểm soát thay đổi suốt vòng đời.
4. Phê duyệt bởi DO với mức A, B, C.
5. Phát hành LSAP/DFLD có hồ sơ: Form 1, Letter of Acceptance.
6. Nạp theo quy trình, cùng phiên bản, có thể cách ly.
7. Kiểm chứng bằng checksum/CRC và chương trình verify.
8. Ghi hồ sơ: phiên bản, SB, ngày, sổ đăng ký.

Checksum, CRC và số mức xác suất

• b_igiá trị byte thứ i của tệp
• mod 256chỉ giữ 8 bit thấp, vì checksum chỉ có 1 byte
• Gmã sinh (generator), cả bên gửi lẫn bên nhận đều biết trước
• modulo-2phép cộng/trừ không nhớ, chính là cổng XOR (Floyd bảng 2-9)

📜 Bối cảnh lý thuyết và lịch sử

Theo bài giảng, nhu cầu kiểm soát phần mềm xuất hiện khi máy bay hiện đại chứa hàng triệu dòng mã trong hàng chục máy tính. RTCA công bố DO-178B năm 1992 và EUROCAE công bố bản tương đương ED-12B; FAA và EASA dùng chúng để xét xem phần mềm có chạy tin cậy trên máy bay hay không. Ban đầu phần lớn mã viết tay; về sau việc sinh mã tự động từ mô hình (MATLAB, Simulink, Embedded Coder) phổ biến, nên cần làm rõ ranh giới giữa yêu cầu hệ thống cấp cao và yêu cầu phần mềm cấp thấp, và cần cách kiểm chứng phần mềm sinh từ mô hình. Vì vậy DO-178C ra đời năm 2011; tháng 7 năm 2013 FAA ban hành thông tư AC 20-115C công nhận DO-178C là phương tiện tuân thủ cho khía cạnh phần mềm của hệ thống trên không.

🔎 Case study: nạp phần mềm cho bộ điều khiển động cơ điện tử (EEC)

Tooley mô tả quy trình nạp EEC bằng thiết bị nạp cầm tay PDL. Tắt nguồn EEC, nối cáp PDL vào bộ nạp rồi vào EEC, cấp 28 V DC cho bộ nạp, bật 115 V AC (400 Hz) cho EEC, kiểm tra đúng đĩa phiên bản phần mềm (cùng phiên bản cho cả động cơ trái lẫn phải) và đĩa không bị khoá ghi, rồi nạp trong khoảng 12 đến 16 phút. Nếu thành công, PDL hiện LOAD COMPLETE; nếu đèn lỗi truyền sáng, kiểm tra cáp và thử lại, tối đa ba lần. Cuối cùng chạy chương trình kiểm tra bộ nhớ: PASS cho số hiệu phần cứng và checksum thì EEC đã được lập trình đúng, rồi ghi phiên bản phần mềm, số Service Bulletin và ngày lên nhãn kim loại của EEC. Mỗi bước tương ứng với một nguyên tắc của module: đúng phiên bản (truy vết), có kiểm tra toàn vẹn (checksum), có hồ sơ (phát hành có kiểm soát).

⚠️ Bẫy hay gặp (và chỗ bài giảng chưa đầy đủ)

Bẫy phổ biến: cho rằng checksum và CRC chứng minh phần mềm đúng. Chúng chỉ phát hiện tệp bị thay đổi; Tooley nói rõ không phương pháp nào tuyệt đối an toàn (xem Demo 1: đổi chỗ hai byte hoặc hai lỗi triệt tiêu nhau qua mặt được checksum). Bẫy thứ hai: nhầm FLS với DFLD; DFLD là dữ liệu, nhưng vẫn phải có số hiệu và hồ sơ phát hành riêng như mã chạy. Một chỗ bài giảng chưa đầy đủ: Câu hỏi 13-6 hỏi trace nào chỉ bắt buộc ở mức A, đáp án in chỉ nêu mã nguồn với mã đối tượng thực thi, nhưng Hình 13-1 của chính bài giảng vẽ hai mũi tên đỏ (chỉ mức A): ngoài mã nguồn với mã đối tượng còn có kiến trúc phần mềm với yêu cầu cấp cao. Tooley dùng cả "Level" (bảng 13.1) lẫn "Class" (câu trắc nghiệm 4) cho cùng một khái niệm. Về Floyd: phép chia CRC trong mục 2-12 thêm số chữ số 0 bằng số bit của mã sinh (4 bit thì thêm 4 số 0), trong khi CRC chuẩn thêm số bit của mã sinh trừ 1; cả hai đều cho phần dư 0 khi nhận đúng, nên đây chỉ là khác biệt về cách trình bày, không phải lỗi.