Bởi Ann Keffer, Arun Gogineni và James Kim

Ô tô triển khai các tính năng ADAS và AV dựa vào các hệ thống analog và kỹ thuật số phức tạp để thực hiện các ứng dụng thời gian thực quan trọng. Số lượng lớn các lỗi cần được kiểm tra trong các thiết kế ô tô hiện đại này khiến việc thực hiện xác minh an toàn bằng một công nghệ duy nhất là không thực tế.

Tuy nhiên, việc phát triển một phương pháp an toàn được tối ưu hóa với danh sách lỗi cụ thể được nhắm mục tiêu tự động để mô phỏng, mô phỏng và chính thức là một thách thức. Một thách thức khác là việc tổng hợp các kết quả giải quyết lỗi từ các lần chạy chèn lỗi khác nhau để tính toán số liệu cuối cùng.

Tin vui là khả năng tương tác của động cơ phun lỗi, kỹ thuật tối ưu hóa và quy trình tự động có thể giảm thiểu hiệu quả thời gian thực hiện tổng thể để nhanh chóng hoàn thiện vòng lặp từ phân tích an toàn đến chứng nhận an toàn.

Hình 1 cho thấy một số kỹ thuật tối ưu hóa trong quy trình an toàn. Các phương pháp nâng cao như phân tích an toàn để tối ưu hóa và cắt tỉa lỗi, mô phỏng lỗi đồng thời, mô phỏng lỗi và phân tích dựa trên chính thức có thể được triển khai để xác thực các yêu cầu an toàn cho SoC ô tô.

Sung 1: Lỗi tối ưu hóa kỹ thuật.

Bằng chứng về khái niệm: SoC ô tô

Bằng cách sử dụng trường hợp kiểm tra cấp độ SoC, chúng tôi sẽ chứng minh cách luồng đa động cơ tự động này xử lý số lượng lớn lỗi cần được kiểm tra trong các thiết kế ô tô tiên tiến. Thiết kế SoC mà chúng tôi sử dụng trong trường hợp thử nghiệm này có khoảng ba triệu cổng. Đầu tiên, chúng tôi sử dụng cả công cụ đưa ra lỗi mô phỏng và mô phỏng để hoàn thành các chiến dịch lỗi cho các chỉ số cuối cùng một cách hiệu quả. Sau đó, chúng tôi thực hiện phân tích chính thức như một phần của việc hoàn thiện việc đưa lỗi tổng thể vào.

Sung 2: Ô tô SoC cấp cao nhất chặn sơ đồ.

Hình 3 là hình minh họa của khối đảo an toàn từ Hình 2. Các khu vực được mã hóa màu cho biết nơi mô phỏng, mô phỏng và động cơ chính thức được sử dụng để chèn lỗi và phân loại lỗi.

Sung 3: Chi tiết đảo an toàn chặn sơ đồ.

Việc đưa lỗi bằng cách sử dụng mô phỏng quá tốn thời gian và tài nguyên cho lõi CPU và các khối bộ nhớ đệm. Những khối đó được nhắm mục tiêu chèn lỗi bằng một công cụ mô phỏng để đạt hiệu quả. Lõi CPU được bảo vệ bởi thư viện kiểm tra phần mềm (STL) và bộ nhớ đệm được bảo vệ bởi ECC. Giao diện bus yêu cầu bảo vệ từ đầu đến cuối trong đó việc chèn lỗi bằng mô phỏng được xác định là hiệu quả. Đơn vị quản lý lỗi không phải là một phần của thử nghiệm này. Bước tiếp theo là việc đưa lỗi cho đơn vị quản lý lỗi sẽ được hoàn thành bằng cách sử dụng công nghệ chính thức.

Bảng 1 cho thấy số lượng thanh ghi cho các khối trong đảo an toàn.

Bảng 1: Số lượng thanh ghi khối.

Danh sách lỗi được tạo cho từng khối này đã được tối ưu hóa để tập trung vào các nút quan trọng về an toàn có cơ chế/bảo vệ an toàn.

SafetyScope, một công cụ phân tích an toàn, đã được chạy để tạo danh sách lỗi cho FM cho cả Ứng dụng Veloce Fault (trình mô phỏng lỗi) và trình mô phỏng lỗi, đồng thời ghi danh sách lỗi vào cơ sở dữ liệu an toàn chức năng (FuSa).

Đối với các khối bộ nhớ CPU và bộ nhớ đệm, trình mô phỏng nhập các khối tổng hợp và mạng phát hiện lỗi/lỗi chèn (FIN/FDN). Tiếp theo, nó thực thi kích thích và nắm bắt trạng thái của tất cả các FDN. Các trạng thái đã được lưu và sử dụng làm tài liệu tham khảo “vàng” để so sánh với các lần chạy chèn lỗi. Đối với mỗi lỗi được liệt kê trong danh sách lỗi được tối ưu hóa, hành vi lỗi được mô phỏng và FDN được so sánh với các giá trị tham chiếu được tạo trong quá trình chạy vàng, đồng thời kết quả được phân loại và cập nhật trong cơ sở dữ liệu lỗi với các thuộc tính.

Hình 4: Cụm CPU. (Nguồn từ https://developer.arm.com/Processors/Cortex-R52)

Đối với mỗi bộ phận phụ được hiển thị trong sơ đồ khối, chúng tôi đã tạo danh sách lỗi được tối ưu hóa bằng công cụ phân tích. Danh sách lỗi được lưu vào từng phiên riêng lẻ trong cơ sở dữ liệu FuSa. Chúng tôi đã sử dụng phương pháp lấy mẫu ngẫu nhiên thống kê về các lỗi tổng thể để tạo mẫu ngẫu nhiên từ cơ sở dữ liệu FuSa.

Bây giờ, hãy xem điều gì sẽ xảy ra khi chúng ta lấy một mẫu ngẫu nhiên trong suốt quá trình đưa lỗi bằng cách sử dụng mô phỏng. Tuy nhiên, để xử lý hoàn toàn việc đưa lỗi vào, chúng tôi đã xử lý N mẫu.

Bàn 2: Phát hiện lỗi by sự an toàn các cơ chế.

Bảng 3 cho thấy sự phân bố lỗi tổng thể của tổng số lỗi phù hợp với sự phân bố lỗi của các lỗi được lấy mẫu ngẫu nhiên. Bảng này còn ghi lại tổng số lỗi được phát hiện là 3125 trên tổng số 4782 lỗi. Chúng tôi cũng có thể lập mô hình các lỗi được phát hiện trên mỗi bộ phận phụ và đưa ra tỷ lệ lỗi được phát hiện tổng thể là 65.35%. Dựa trên các lỗi trong mẫu ngẫu nhiên và mục tiêu bao phủ 90% của chúng tôi, chúng tôi đã tính toán rằng tỷ lệ sai số (MOE) là ±1.19%.

Bàn 3: Kết quả của việc đưa lỗi vào CPU và bộ nhớ đệm.

Tổng số 3125 lỗi được phát hiện (được quan sát + không được quan sát) cung cấp sự phân loại lỗi rõ ràng. Những lỗi được quan sát không bị phát hiện cũng cung cấp sự phân loại rõ ràng cho các lỗi Dư. Chúng tôi đã phân tích sâu hơn về các lỗi không được quan sát và không được phát hiện.

Bàn 4: Lỗi phân loại sau khi lỗi mũi tiêm.

Chúng tôi đã sử dụng nhiều kỹ thuật gỡ lỗi để phân tích 616 lỗi Không được phát hiện Không được quan sát. Đầu tiên, chúng tôi sử dụng phân tích chính thức để kiểm tra hình nón ảnh hưởng (COI) của các lỗi UU này. Các lỗi nằm ngoài COI được coi là an toàn và có 616 lỗi tiếp tục bị loại khỏi phân tích. Đối với các lỗi bên trong COI, chúng tôi đã sử dụng phán đoán kỹ thuật với sự biện minh cho các cấu hình khác nhau như ECC, bộ đếm thời gian, bộ nhớ flash liên quan, v.v. Cuối cùng, bằng cách sử dụng phán đoán chính thức và kỹ thuật, chúng tôi có thể phân loại thêm 79 lỗi UU thành các lỗi an toàn và các lỗi còn lại. lỗi UU thành lỗi dư bảo toàn. Chúng tôi cũng đã xem xét 10 lỗi còn sót lại và có thể phân loại 1.293 lỗi thành lỗi an toàn. Các lỗi không được đưa vào cũng được kiểm tra dựa trên mô hình mô phỏng để kiểm tra xem liệu có bất kỳ kích thích nào nữa có thể tạo ra các lỗi đó hay không. Vì không có tác nhân kích thích nào có thể tạo ra những lỗi này nên chúng tôi đã quyết định loại bỏ những lỗi này khỏi sự xem xét của mình và hạn chế sai sót cho phù hợp. Với sự thay đổi này, MOE mới của chúng tôi là ±XNUMX%.

Song song đó, bộ mô phỏng lỗi lấy danh sách lỗi được tối ưu hóa cho các chế độ lỗi của khối bus và chạy mô phỏng lỗi bằng cách sử dụng kích thích từ xác minh chức năng. Nhóm kích thích ban đầu không cung cấp đủ phạm vi bao phủ, do đó, các kích thích có chất lượng cao hơn (vectơ thử nghiệm) đã được chuẩn bị và các chiến dịch lỗi bổ sung được chạy trên các kích thích mới. Tất cả các phân loại lỗi đã được ghi vào cơ sở dữ liệu FuSa. Tất cả các hoạt động đều diễn ra song song và đồng thời để mang lại hiệu quả tổng thể và hiệu suất cao.

Phân tích an toàn bằng cách sử dụng SafetyScope giúp mang lại độ chính xác cao hơn và giảm việc lặp lại mô phỏng lỗi. CPU và bộ nhớ đệm sau khi mô phỏng trong nhiều thử nghiệm khác nhau đã cho kết quả SPFM tổng thể trên 90% như trong Bảng 5.

Bàn 5: Tổng thể kết quả.

Tại thời điểm này, chưa phải tất cả các thử nghiệm đối với khối BUS (bảo vệ từ đầu đến cuối) thực hiện mô phỏng lỗi đã được hoàn thành. Bảng 6 cho thấy thử nghiệm ban đầu có thể giải quyết rất nhanh 9.8% lỗi.

Bàn 6: Tỷ lệ phần trăm lỗi khối BUS được phát hiện bởi E2E SM.

Chúng tôi đang tích hợp nhiều thử nghiệm hơn có lưu lượng truy cập cao trên BUS để mô phỏng trạng thái hoạt động trong thời gian chạy của SoC. Kết quả của việc chèn lỗi độc lập này (mô phỏng và mô phỏng) đã được kết hợp để tính toán số liệu cuối cùng trên các khối trên, với kết quả được hiển thị trong Bảng 7.

Bàn 7: Phân tích bài phân loại lỗi cuối cùng.

Kết luận

Trong bài viết này, chúng tôi đã chia sẻ thông tin chi tiết về phương pháp an toàn chức năng mới được sử dụng trong trường hợp thử nghiệm ô tô ở cấp độ SoC và chúng tôi đã chỉ ra cách phương pháp của chúng tôi tạo ra quy trình làm việc an toàn hiệu quả, có thể mở rộng bằng cách sử dụng các kỹ thuật tối ưu hóa để chèn lỗi bằng các công cụ xác minh chính thức, mô phỏng và mô phỏng. . Việc thực hiện phân tích an toàn trước khi chạy chèn lỗi là rất quan trọng và tiết kiệm thời gian. Do đó, khả năng tương tác để sử dụng nhiều công cụ và đọc kết quả từ cơ sở dữ liệu FuSa chung là cần thiết cho một dự án ở quy mô này.

Để biết thêm thông tin về quy trình an toàn chức năng hiệu quả cao dành cho các thiết kế ô tô ADAS và AV, vui lòng tải xuống báo cáo nghiên cứu chuyên sâu về Siemens EDA Các cơ chế an toàn phức tạp yêu cầu khả năng tương tác và tự động hóa để xác thực và đóng số liệu.

Arun Gogineni là giám đốc kỹ thuật và kiến ​​trúc sư về an toàn chức năng vi mạch tại Siemens EDA.

James Kim là lãnh đạo kỹ thuật tại Siemens EDA.

• Phân phối nội dung và PR được hỗ trợ bởi SEO. Được khuếch đại ngay hôm nay.
• PlatoData.Network Vertical Generative Ai. Trao quyền cho chính mình. Truy cập Tại đây.
• PlatoAiStream. Thông minh Web3. Kiến thức khuếch đại. Truy cập Tại đây.
• Trung tâmESG. Than đá, công nghệ sạch, Năng lượng, Môi trường Hệ mặt trời, Quản lý chất thải. Truy cập Tại đây.
• PlatoSức khỏe. Tình báo thử nghiệm lâm sàng và công nghệ sinh học. Truy cập Tại đây.
• nguồn: https://semiengineering.com/interoperability-and-automation-yield-a-scalable-and-efficient-safety-workflow/