Phần mềm được sử dụng trong các hệ thống sinh tử quan trọng được thử nghiệm như thế nào?

Ví dụ, một chiếc máy bay, trái ngược với một trang web, là một hệ thống mà bất kỳ sự cố nào trong một số hệ thống là hoàn toàn không thể chấp nhận được, vì các lỗi trong ví dụ giám sát chuyến bay có thể khiến máy bay tự động bị trục trặc và lao xuống. Rõ ràng, điều này không xảy ra vì các kỹ sư tài giỏi của Boeing và Airbus đã kiểm tra tự động để đảm bảo rằng nó không đột nhiên quyết định lặn là một thao tác an toàn và chấp nhận được. Hoặc có lẽ máy tính gặp sự cố, và các phi công trong chiếc máy bay bay mới hơn không thể thực sự lái máy bay. Tất nhiên, có nhiều quy trình an toàn và dự phòng được tích hợp trong các hệ thống này để ngăn ngừa sự cố (của cả phần mềm và máy bay).

Tuy nhiên, mặt khác, rõ ràng là phần mềm không hoàn hảo cả phần mềm nguồn mở và phần mềm nguồn đóng thường xuyên bị sập và chỉ có chương trình "Hello World" đơn giản nhất không bị lỗi. Làm thế nào các kỹ sư thiết kế hệ thống phần mềm trong ngành hàng không, y tế và các ngành công nghiệp sinh tử khác có thể quản lý để kiểm tra phần mềm của họ để nó không bị lỗi (và nếu nó thất bại, ít nhất là thất bại một cách duyên dáng)?

_{Tôi tuyệt vọng hy vọng rằng tất cả các bạn sẽ không đi: "Ồ, tôi làm việc cho Boeing / Airbus / (một số công ty khác) và không! Hãy vui vẻ trong chuyến bay tiếp theo / bệnh viện tiếp theo của bạn."}

Tôi đã thực hiện rất nhiều công việc trong kiểm soát công nghiệp. Nó không phải là trong một ngành công nghiệp vinh quang như hàng không vũ trụ. Hầu như mọi máy móc công nghiệp đều có đủ năng lượng tiềm năng để gây thương tích nghiêm trọng hoặc tử vong. Tôi đã ở xung quanh khi mọi người bị thương. Nếu bạn dành phần lớn thời gian của mình tại bàn làm việc trong văn phòng, có lẽ bạn sẽ ngạc nhiên về mức độ nguy hiểm của hầu hết các công việc nhà máy (và chắc chắn là cho đến gần đây). Bây giờ chúng tôi có phương pháp tốt hơn để bảo vệ máy. Đây là cách nó hoạt động trong thực tế (mặc dù nó thay đổi từ quyền tài phán sang quyền tài phán):

Có các tiêu chuẩn OSHA ở Mỹ và các hướng dẫn tương tự (thường nghiêm ngặt hơn) ở EU. Chúng thường bắt đầu bằng cách yêu cầu bạn thực hiện phân tích rủi ro. Điều này có nghĩa là bạn lập một danh sách tất cả các mối nguy hiểm và sau đó phân loại các mối nguy hiểm đó, có tính đến những điều như mức độ thường xuyên mà một người sẽ gặp rủi ro, cách dễ dàng để tránh rủi ro (phụ thuộc vào tốc độ, v.v.), và những gì là mức độ nghiêm trọng của kết quả (cắt, cắt cụt, tử vong, v.v.).

Rất nhiều phân tích có liên quan đến việc bảo vệ các mối nguy hiểm. Nếu bạn đặt một cái lồng lớn xung quanh máy của bạn và siết chặt nó, thì máy của bạn được coi là an toàn nếu các bộ phận của máy không thể vi phạm bảo vệ. Nếu bạn cần một công cụ để vào, đó được coi là một nhiệm vụ bảo trì và những người bảo trì được cho là được đào tạo về cách làm việc an toàn trên máy. Tuy nhiên, trên thực tế, hầu hết các máy móc đều cần sự tương tác thường xuyên với người vận hành, vì vậy chúng ta phải đặt cửa truy cập trong bảo vệ, hoặc rèm sáng, v.v. Những cánh cửa và rèm cửa nhẹ đó cần được giám sát và sức mạnh đối với các mối nguy hiểm mà người vận hành đang phơi bày phải được tắt theo cách "kiểm soát đáng tin cậy".

Dựa trên phân tích đó, rủi ro được đưa vào các loại khác nhau. Thang đo phân loại phổ biến là Loại 1 đến Loại 4 (dựa trên tiêu chuẩn EN 954-1). Dựa trên các danh mục đó, bạn được yêu cầu về mặt pháp lý để cung cấp một mức độ bảo vệ và an toàn máy nhất định.

Ví dụ, loại 4 yêu cầu:

Một lỗi trong mỗi bộ phận này không làm mất chức năng an toàn.

Lỗi đơn được phát hiện có hoặc trước yêu cầu tiếp theo đối với chức năng an toàn hoặc nếu điều này là không thể, việc tích lũy các lỗi có thể không gây ra mất chức năng an toàn.

Điều này có thể khó đạt được trong thực tế, nhưng được thực hiện đơn giản hơn bởi sự sẵn có của các thành phần tiêu chuẩn được chứng nhận cho Loại 4. Ví dụ, một thành phần phổ biến trong các hệ thống này là Rơle an toàn. Đây không chỉ là rơle cơ học:

• Chúng được thiết kế để giám sát các kênh đầu vào dự phòng kép, vì vậy nếu bạn có cảm biến phát hiện tình trạng lỗi (như cửa bảo vệ mở), nó thường có hai tiếp điểm với các mạch dự phòng. Rơle giám sát cả hai kênh và nếu một trong hai mở ra, nó sẽ mất điện cho các bộ truyền động của bạn, nhưng nếu cả hai không rơi ra cùng một lúc, thì nó sẽ gặp tình trạng lỗi và máy không thể được khởi động lại cho đến khi được sửa chữa .
• Rơle cũng sử dụng các xung điện trên các đường dây đó và sử dụng các tín hiệu đó để theo dõi các dây bị cắt ngang hoặc ngắn, do đó nó có thể phát hiện ra lỗi nối dây.
• Về phía đầu ra, nó sử dụng một bộ các mạch kép để điều khiển các cuộn dây đầu ra, vì vậy nếu một lỗi xảy ra trong điều kiện "bật", thì cái kia sẽ ngăn không cho đầu ra được cấp điện. Ngoài ra, những thứ này được theo dõi và nếu một lỗi được phát hiện, nó sẽ ngăn hoạt động. Bản thân các cuộn dây thực sự là các rơle dẫn hướng hai lực có nghĩa là các rơle vật lý dự phòng trên đầu ra, cộng với việc đảm bảo rằng các tiếp điểm trên mỗi rơle đơn được liên kết vật lý với nhau để một tiếp điểm ngoài, nói 4, không thể bị kẹt bởi chính nó. Những điều này cũng được theo dõi.
• Nó cũng bao gồm một đầu vào để giám sát một tiếp điểm phụ thường đóng ngoài tải mà bạn đang kiểm soát. Nếu nó tắt đầu ra, nó phải xem tiếp điểm đóng thông thường có nghĩa là nó xác nhận rằng nó đã tắt công tắc tơ, hoặc bất cứ thứ gì, trước khi nó được phép hoạt động trở lại.

Như bạn có thể nói, đây là những thiết bị phức tạp. Chi phí điển hình nằm trong khoảng 200 đến 600 đô la cho mỗi rơle an toàn. Rõ ràng là có phần mềm trong các thiết bị này. Để được chứng nhận rơle an toàn, bạn thường phải tuân theo một thiết kế như thế này:

• Hai bộ xử lý dự phòng, thường có nguồn gốc từ các nhà cung cấp khác nhau, dựa trên các thiết kế khác nhau.
• Mã chạy trên mỗi bộ xử lý phải được phát triển bởi hai nhóm làm việc trong các điều kiện riêng biệt. Điều này ngăn một lỗi phần mềm duy nhất là một điểm lỗi duy nhất.
• Đầu ra của cả hai bộ xử lý phải đồng ý nếu không các lỗi rơle an toàn.

Khi bạn thiết kế hệ thống an toàn cho máy của mình, sử dụng các bộ phận được xếp hạng an toàn, sau đó bạn phải nhận được thiết kế được xem xét và đóng dấu bởi một Kỹ sư chuyên nghiệp. Sau đó, bạn xây dựng máy. Sau đó là P.Eng. sẽ xem xét việc xây dựng máy để đảm bảo nó được chế tạo theo thiết kế. Họ sẽ ghi lại nó và sẽ thực hiện một số thử nghiệm trên đó để đảm bảo nó hoạt động như mong đợi. Điều này được gọi là đánh giá trước khi bắt đầu (PSR) và không được thực hiện trong mọi khu vực tài phán. Sau khi PSR vượt qua, khi đó bạn được phép có một nhà điều hành chạy máy.

Trong những năm gần đây đã có một số cuộc cách mạng trong các hệ thống an toàn. Trong một thời gian, không ai tin tưởng truyền dữ liệu an toàn qua mạng, do đó, cái gọi là "hệ thống I / O phân tán" như DeviceNET và EtherCAT không được phép trong phần an toàn của hệ thống. Tuy nhiên, các giao thức gần đây hiện cho phép các thiết bị an toàn chạy trên các mạng công nghiệp này. Các giao thức sử dụng các thông điệp được đóng dấu thời gian và xử lý dự phòng kép ở cả hai đầu của kết nối.

Rơle an toàn đang dần đi theo con chim dodo, được thay thế bằng các PLC An toàn phức tạp hơn, giống như một cách để xây dựng logic an toàn trong ngôn ngữ sơ đồ khối chức năng. Một lần nữa, các PLC an toàn này sử dụng mọi thứ dư thừa. Khi chương trình được phê duyệt, trước khi máy được đưa vào sử dụng, P.Eng. sẽ đóng dấu chương trình và chương trình / PLC sẽ bị khóa bằng mật khẩu. Nó cũng lấy một hàm băm của chương trình và hàm băm đó được ghi lại trong tài liệu (đó là những gì P.Eng. Thực sự bị dập).

Bây giờ khi bạn đã thiết kế hệ thống an toàn của mình, logic bạn viết để điều khiển chính máy có thể rất phù hợp với bạn. Các lập trình viên thường xuyên gặp sự cố máy móc gây ra thiệt hại hàng ngàn đô la, nhưng ít nhất sẽ không có ai bị thương.

Có một động thái nghiêm túc đối với xác minh chính thức thay vì thử nghiệm chức năng ngẫu nhiên.

Các cơ quan chính phủ như NASA và một số tổ chức quốc phòng đang chi tiêu ngày càng nhiều cho các công nghệ này.

Họ vẫn là một PITA cho lập trình viên trung bình, nhưng họ thường hiệu quả hơn trong việc kiểm tra các hệ thống quan trọng.

Cũng có xu hướng thử nhiều kỹ thuật hơn từ giới hàn lâm, cho những việc như xác nhận mã đa luồng.

Nó phụ thuộc vào phần mềm là gì. Ví dụ, trong các mặt phẳng thường có xử lý dự phòng kép cho các hệ thống quan trọng; trong trường hợp cực đoan, có thể có 2 thiết kế phần cứng khác nhau được sử dụng và hai phần s / w được phát triển độc lập, một phần để chạy trên mỗi phần. Cả hai tính toán và kiểm tra chéo lẫn nhau. Điều này không phải là hoàn hảo và cực kỳ tốn kém.

Khi nói đến những thứ như thử nghiệm hệ thống máy bay, có một loạt các thử nghiệm được thực hiện - thử nghiệm hệ thống liên quan đến chuyến bay mất nhiều tháng, và nếu bạn thực hiện bất kỳ thay đổi nào trong toàn bộ một loạt các thử nghiệm lại thì phải chạy. Điều này thường được thực hiện trong một trình giả lập, có thể thực sự chứa đầy các bộ phận máy bay thật (ví dụ như buồng lái) với động cơ mô phỏng hoặc tương tự. Như bạn có thể tưởng tượng, nó cũng rất tốn kém để xây dựng. Các thay đổi được đánh giá theo chương trình thử nghiệm chính thức, sau đó chạy trên một chiếc máy bay thực trong các chuyến bay thử nghiệm. Theo cách mà các thử nghiệm như "chức năng bị xáo trộn" được chạy, đây là nơi vật phẩm thay đổi được phép làm công việc bình thường của nó và mọi thứ đều được kiểm tra / thử nghiệm để thấy rằng không có tác dụng xấu. Điều này cũng tốn rất nhiều tiền và có thể mất vài tuần.

Tôi biết một ví dụ trong đó yêu cầu thay đổi rất đơn giản đối với hệ thống máy bay - đơn giản đến mức bạn sẽ bị choáng khi biết trẻ vị thành niên. Tuy nhiên, việc kiểm tra lại việc này sẽ mất> 3 tháng và tiêu tốn khoảng 1 triệu đô la.

Khi bạn vào ngành y, có cả một loạt các rào cản pháp lý để nhảy không chỉ liên quan đến thử nghiệm mà còn cả các quy trình và tài liệu phát triển.

Tất cả các lĩnh vực này là một bước tiến lớn từ một nơi tạo ra một chút mã PHP cho một trang web. Đó là chậm, siêng năng, khó khăn, nhàm chán, tẻ nhạt, tỉ mỉ và rất tốn kém. Lấy chi phí phát triển / kiểm tra bình thường của bạn và nhân với khoảng 100 và bạn đang tiến gần đến điểm.

Đối với phần mềm tàu ​​con thoi của NASA, hãy đọc They Write the Right Stuff . Đối với FDA (Cục quản lý thực phẩm và dược phẩm Hoa Kỳ) hãy đọc điều này

Vì bạn đã có đủ câu trả lời tuyệt vời và nhiều thông tin, đây là tôi.

Thật đơn giản - bài kiểm tra đầu tiên luôn được thực hiện trên chính các lập trình viên. Nó có xu hướng giữ số lượng lỗi thấp và đảm bảo rằng chỉ những lập trình viên chất lượng mới được giữ trong bảng lương.

Phần mềm quan trọng trong cuộc sống không được thử nghiệm theo bất kỳ tiêu chuẩn nào ngoài tiêu chuẩn "có vẻ như hoạt động" , vì nó được thực hiện ở mọi nơi.

Tất cả các khoản đầu tư đều đi vào những gì dường như hoạt động trước đây hoặc cho các dự án để cho phép những người không lập trình viên sản xuất phần mềm tốt hơn .

ps Không có ý kiến ​​nào về người đầu tiên -1, nhưng tôi rất vui khi nhận được -1từng tham chiếu phản ánh tuyên bố của tôi.

Tôi có thể lấy +1 cho mọi tham chiếu mà tôi tìm thấy đối với phần mềm quan trọng không được thiết kế hoặc kiểm tra tốt không? Simson Garfinkel ghi lại mười trường hợp trong một bài viết về WIRED.

Không có một câu trả lời cho tất cả các trường hợp. Tùy thuộc vào nhà sản xuất để quyết định cách thiết kế và kiểm tra phần mềm của họ. Nhưng toàn bộ quá trình phát triển phần mềm phải tuân thủ các thông số kỹ thuật chính thức.

Ví dụ: khi tạo phần mềm cho các thiết bị y tế, bạn phải tuân theo tiêu chuẩn IEC 62304 cho phần mềm cho các thiết bị y tế. (Thật không may, tôi chỉ có thể liên kết đến wikipedia vì nó không miễn phí). Khá nhiều quốc gia trên thế giới yêu cầu tiêu chuẩn này phải được tuân theo.

Làm thế nào nghiêm ngặt những yêu cầu này phụ thuộc vào nguy cơ gây hại. Ví dụ, một thiết bị hỗ trợ sự sống sẽ có nguy cơ gây hại lớn nhất (cái chết nhất định mà hệ thống bị hỏng), trong khi đó một hệ thống hoạt động với chẩn đoán bệnh có rủi ro thấp hơn (có thể tử vong nếu bệnh aa không được chẩn đoán chính xác nếu hệ thống bị lỗi).

Nhưng điều này về cơ bản là phải có khả năng truy nguyên nguồn gốc từ các yêu cầu đối với phần mềm. Bạn phải thực hiện xác minh đơn vị phần mềm. Điều đó không xác định xác minh là gì. Có thể là bài kiểm tra đơn vị, có thể được xem xét mã. Đối với các thiết bị có rủi ro cao hơn, bạn phải xem xét thủ công các giao diện giữa các đơn vị phần mềm (theo như tôi hiểu và ghi nhớ). Và tất nhiên rất nhiều quy tắc khác. Ồ, và bạn phải viết rất nhiều tài liệu để ghi lại công việc của bạn.

Tiêu chuẩn không cấm phát triển nhanh, mặc dù khi đọc nó có vẻ như nó được viết với sự phát triển của thác nước trong tâm trí.

Tôi không biết về các lĩnh vực phát triển phần mềm khác, như hàng không, xe lửa, ô tô, v.v. Nhưng tôi cho rằng các hướng dẫn chính thức tương tự khác tồn tại.

Nhiều kỹ thuật được sử dụng, bao gồm nhưng không giới hạn ở:

• thiết kế chính thức và / hoặc xác nhận
• các tiêu chuẩn mã hóa nghiêm ngặt tránh lập trình ưa thích như phân bổ bộ nhớ động
• kỹ sư chất lượng rất khắt khe
• nhiều kỹ thuật phân tích tĩnh như xem lại mã, cây lỗi, FMECA, ...

Nhưng kỹ thuật số một là:

• KIỂM TRA

Phần mềm của tàu vũ trụ cần nhiều nỗ lực để kiểm tra hơn là thiết kế và viết mã ngay từ đầu.

Máy bay trải qua nhiều năm thử nghiệm chuyến bay trong đó máy bay bị đưa vào tình huống khắc nghiệt. Thử nghiệm này không chỉ cấu trúc vật lý mà còn cả phần mềm.

Có một bài viết "Phần mềm hoàn hảo" của Jack Ganssle trên EETimes ngày 3/1/2009 12:00 AM EST. Một vài điểm từ đó:

• "Về mặt lý thuyết, Phần mềm là thành phần duy nhất có thể hoàn hảo và đây luôn là điểm khởi đầu của chúng tôi." - Đó là lời nói của Jesse Poore. Theo dõi trang web của anh ấy, bạn sẽ tìm ra cách phần mềm hoàn hảo có thể được tạo ra mà không tốn nhiều chi phí hơn phần mềm thông thường.
• Có những nhà cung cấp công nghiệp của hệ điều hành có độ tin cậy cao. Bài báo đã đề cập đến Mircrium và Green Hills. Theo dõi trang web của Micrium, có danh sách các tiêu chuẩn để chứng nhận. Đó phải là các quy trình và quy tắc ngành công nghiệp tuân theo. Điều đó dựa trên xác nhận chính thức, nhưng chuyển hướng từ lý thuyết rất nhiều.

Thật thú vị, liên quan đến phần mềm thương mại, dữ liệu do Capers Jones thu thập cho thấy rằng "phần mềm nói chung có hiệu quả loại bỏ lỗi (tỷ lệ lỗi được loại bỏ trước khi vận chuyển) là 87%. Phần sụn đạt tỷ lệ cực kỳ tốt 94%." Đối với tôi, không ai trong số này gần hoàn hảo. Bài báo mà một người trả lời trước đó đã đề cập chỉ ra rằng nhóm tàu ​​con thoi của NASA đã đạt được tỷ lệ loại bỏ lỗi 99%, nhưng chi phí ở mức 35 triệu mỗi năm cho khoảng 400 nghìn dòng mã.

Một bài viết thú vị hơn "Phần mềm cho các hệ thống đáng tin cậy" của cùng một tác giả vào ngày 11/1/2009, dường như có liên quan hơn. Nó có thể được tóm tắt như thế này:

• Theo quy trình phát triển, ngành công nghiệp đã tuân theo DO-178B hoặc IEC61508. Nó nhấn mạnh thử nghiệm với phạm vi bảo hiểm lớn nhất. Nhưng ít bằng chứng có thể được tìm thấy về hiệu quả của việc này.
• Một cơ quan chứng nhận, Ủy ban về các hệ thống phần mềm đáng tin cậy, đã xuất bản một cuốn sách có tựa đề "Phần mềm cho các hệ thống đáng tin cậy - Bằng chứng đầy đủ". Đó là một tài liệu tham khảo tốt.
• Cuốn sách, về cơ bản yêu cầu ba điều: [1] Tạo quy tắc rõ ràng cho các bài kiểm tra độ tin cậy. [2] Các thử nghiệm chống lại các quy tắc, nhưng cũng đảm bảo rằng các thử nghiệm có thể hiểu được bởi các khách hàng hoặc nhà quản lý bình thường với thời gian ít hơn so với các nhà phát triển đã bỏ ra. [3] Hãy chắc chắn rằng các chuyên gia về công nghệ phần mềm và miền vấn đề đang thực hiện phát triển và thử nghiệm.
• Nhà cung cấp phần mềm phải cam kết bảo hành hoặc các biện pháp khắc phục khác cho bất kỳ lỗi phần mềm nào.
• Sử dụng ngôn ngữ an toàn, cụ thể là không C. SPARK được đề xuất.
• Thiết kế cho cách tiếp cận hợp đồng là một trong những thế mạnh của SPARK. Design-for-Contract là một công nghệ quan trọng để nhúng các kiểm tra vào mọi lệnh gọi hàm / phương thức và luôn thực hiện nó khi chạy. Không chỉ là một khẳng định đơn giản () ngày xưa, hợp đồng cũng có thể nhúng các thử nghiệm chống lại ý định cấu trúc và đảm bảo không có vi phạm nào có thể bị trượt vào những lần sau trong chu kỳ bảo trì khi các nhà phát triển ban đầu chủ yếu chuyển sang các dự án khác. Có bằng chứng cho thấy thiết kế cho hợp đồng đã tạo ra các sản phẩm phần mềm rất đáng tin cậy. SPARK và các công cụ của nó có thể được sử dụng để hỗ trợ tạo các trường hợp kiểm tra chứng nhận để đơn giản hóa quy trình chứng nhận.

Theo trí nhớ của tôi, HP đã thực hành thiết kế theo hợp đồng gần một thập kỷ trước. Với một nhóm nhỏ, 500k dòng mã, chỉ có 2 lỗi được báo cáo sau khi giao hàng. Rất ấn tượng.

Theo quan điểm của tôi, phần mềm đáng tin cậy hoặc hoàn hảo chỉ có thể đạt được nếu chi phí không quá cao. Khung hoặc tự động hóa là phải có.

Chúng thường có khóa liên động phần cứng được sử dụng là không an toàn.

Ví dụ: thiết kế hộp văn bản ác tiêu chuẩn cho robot giết người luôn đi kèm với công tắc tiêu diệt: P

Mỗi ngành công nghiệp có tập hợp các cơ quan quản lý riêng có các yêu cầu kiểm tra và tài liệu về phần cứng và phần mềm liên quan đến an toàn. Hãy xem xét bản PDF này từ Phòng thí nghiệm Underwriters (UL) giới thiệu tiêu chuẩn UL 1998: http://www.ul.com/global/document/offerings/industries/hightech/software/UL_softwareconformityassessment.pdf

Có tài liệu tham khảo trong tài liệu đó cho nhiều tài liệu liên quan khác từ UL, CSA và IEC.

Thông thường, phần mềm liên quan đến an toàn sẽ có các mạch phần cứng dự phòng hoặc được yêu cầu phải có các tính năng kiểm soát dự phòng khác để đảm bảo hoạt động an toàn và các chế độ lỗi an toàn.