Mô hình lỗi cho các hệ thống nhúng

Tôi có một mạch cảm biến không dây với một vi điều khiển và mô-đun thu phát 2,4 GHz , một số cảm biến tích hợp với giao diện I²C, cổng UART và các thành phần riêng biệt cần thiết.

Bảng này được thiết kế để quét năng lượng từ bảng điều khiển năng lượng mặt trời (PV), với pin LiPo và bộ sạc shunt . Điều này cho phép cảm biến tự cấp nguồn và hoạt động trong một thời gian không xác định, yêu cầu bảo trì ít nhất có thể.

Tôi muốn khám phá các lỗi có thể xảy ra trong một hệ thống như thế này và đó có thể là do lão hóa, vi phạm thông số kỹ thuật môi trường (nhiệt độ, độ ẩm, v.v.) hoặc bảo trì sai (không phải lỗi thiết kế / lỗi), trong để tối đa hóa tuổi thọ hoạt động của nó.

Môi trường mà nút cảm biến hoạt động là một tòa nhà, được gắn vào trần nhà hoặc các bức tường. Vì vậy, nhiệt độ cực đoan hoặc mưa không được xem xét.

Những gì tôi đã đưa ra là một số lỗi mà tôi cố gắng tóm tắt:

• Thành phần bị hỏng -> mở \ ngắn mạch
• Cảm biến bị lỗi -> giá trị đầu ra sai (nhưng làm thế nào sai?)
• Xác định cách ly do bụi \ nước -> tăng rò rỉ
• Nhiệt độ ngoài phạm vi -> ???

Làm thế nào tôi có thể ước tính làm thế nào nút cảm biến sẽ thất bại, và tại sao?

Có quá nhiều mức độ tự do để hiểu "tất cả" các lỗi có thể xảy ra. Tuy nhiên, có các kỹ thuật để xác định và giảm thiểu lỗi sớm trong chu trình thiết kế (tức là trước khi phát hành rộng).

Kích hoạt thời gian thiết kế (phần cứng trước)

Đánh giá ngang hàng luôn là một cách tuyệt vời để tìm lỗi. Nhờ người khác phân tích thiết kế của bạn và sẵn sàng bảo vệ trước các câu hỏi của họ (hoặc thừa nhận rằng họ đã tìm thấy một lỗi và sửa nó!) Không có sự thay thế nào cho sự xem xét kỹ lưỡng và đôi mắt mới thường nhìn thấy những thứ bị bỏ qua bởi những người mệt mỏi. Điều này hoạt động cho cả phần cứng và phần mềm - sơ đồ có thể được xem xét dễ dàng như mã nguồn.

Đối với phần cứng, như những người khác đã nói, DFMEA ( Thiết kế thất bại trong thiết kế và phân tích hiệu ứng ) là một khuyến nghị tốt. Đối với mỗi thành phần, hãy tự hỏi mình "điều gì xảy ra nếu quần short này ra ngoài" và "điều gì xảy ra nếu điều này xảy ra" và lập biên bản phân tích của bạn. Đối với IC, cũng hãy tưởng tượng điều gì sẽ xảy ra nếu các chân liền kề được nối ngắn với nhau (cầu hàn, v.v.)

Đối với phần sụn, các công cụ phân tích mã tĩnh (MISRA, lint, v.v.) có thể được sử dụng để tiết lộ các lỗi ẩn trong mã. Những thứ như con trỏ nổi và bình đẳng thay vì so sánh (= vs ==) là những 'oopsies' phổ biến mà các công cụ này sẽ không bỏ lỡ.

Một lý thuyết hoạt động bằng văn bản cũng rất hữu ích, cho cả phần cứng và phần mềm. Một lý thuyết vận hành cần mô tả ở mức độ khá cao về cách thức hoạt động của hệ thống, cách thức bảo vệ hoạt động, giải trình tự, v.v ... Đơn giản chỉ cần đặt từ ngữ làm thế nào logic nên chảy thường dẫn đến một nhận ra rằng một số trường hợp có thể đã bị bỏ qua ("Ừm, Waitasec, còn tình trạng này thì sao? ")

Kiểm tra mức độ nguyên mẫu

Khi bạn đã có phần cứng trong tay, đã đến lúc bắt đầu "làm việc".

Sau khi tất cả các phân tích lý thuyết được thực hiện, điều quan trọng là phải mô tả chính xác cách thức thiết bị hoạt động trong thông số kỹ thuật. Điều này thường được gọi là kiểm tra xác nhận hoặc trình độ. Tất cả các thái cực cho phép cần phải được kiểm tra.

Một hoạt động trình độ quan trọng khác là phân tích căng thẳng thành phần. Mỗi phần được đánh giá theo điện áp / dòng / nhiệt độ tối đa của nó, trong một điều kiện hoạt động xác định. Để đảm bảo độ bền, nên áp dụng hướng dẫn giảm giá thích hợp (không vượt quá 80% điện áp, 70% điện năng, v.v.)

Chỉ khi bạn biết mọi thứ trong điều kiện bình thường như thế nào, bạn mới có thể bắt đầu suy đoán về những bất thường bên ngoài, hoặc nhiều bất thường như bạn đang mô tả. Một lần nữa, mô hình DFMEA (điều gì xảy ra nếu X xảy ra) là một cách tiếp cận tốt. Hãy nghĩ về bất kỳ điều gì có thể mà người dùng có thể làm với thiết bị - đầu ra ngắn, liên kết các tín hiệu với nhau, làm đổ nước lên nó - thử chúng và xem điều gì sẽ xảy ra.

Một thử nghiệm HALT (thử nghiệm cuộc sống tăng tốc cao ) cũng hữu ích cho các loại hệ thống này. Thiết bị được đưa vào buồng môi trường và được thực hiện từ nhiệt độ tối thiểu đến tối đa, đầu vào và đầu ra tối thiểu và tối đa, có rung. Điều này sẽ tìm thấy tất cả các loại vấn đề, cả điện và cơ khí.

Đây cũng là thời điểm tốt để thực hiện một số thử nghiệm fuzz nhúng - thực hiện tất cả các yếu tố đầu vào vượt quá phạm vi dự kiến ​​của chúng, gửi thông tin sai lệch thông qua UARTs / I2C, v.v. để tìm lỗ hổng trong logic. (Chẳng hạn, các thói quen I2C có tiếng là khét tiếng để khóa xe buýt.)

Thử nghiệm Strife là một cách tốt để chứng minh sự mạnh mẽ. Vô hiệu hóa bất kỳ tính năng bảo vệ nào như quá nhiệt độ, quá tải, vv và áp dụng căng thẳng cho đến khi một cái gì đó bị phá vỡ. Đưa thiết bị lên nhiệt độ cao nhất có thể cho đến khi xảy ra sự cố hoặc một số hành vi thất thường xảy ra. Quá tải thiết bị cho đến khi hệ thống truyền động không thành công. Nếu một số tham số chỉ thất bại một chút so với các điều kiện trong trường hợp xấu nhất, thì đó là dấu hiệu của tỷ lệ cận biên và một số xem xét thiết kế có thể phải được xem xét lại.

Bạn cũng có thể thực hiện phương pháp cấp độ tiếp theo và kiểm tra thực tế một số kết luận DFMEA của bạn - thực sự làm quần short và mở và pin-shorts và xem những gì nổ tung.

đọc thêm

Nền tảng của tôi là trong chuyển đổi năng lượng. Chúng tôi có một tiêu chuẩn công nghiệp gọi là IPC-9592A , đây là một nỗ lực để tiêu chuẩn hóa cách các sản phẩm phải đủ tiêu chuẩn về các thử nghiệm và cách thực hiện chúng. Nhiều loại thử nghiệm và phương pháp được đề cập trong tài liệu này có thể dễ dàng được sử dụng trong các ngành điện khác.

Với nhiều thiết bị trên giao diện I2C, bạn có thể gặp phải sự cố "ngốc bập bẹ" khi một thiết bị bị lỗi, làm hỏng I2C và giết chết tất cả các truyền I2C khác.

Thử nghiệm ngâm kết hợp với thử nghiệm môi trường sẽ cung cấp một hình thức phân tích lỗi khác nhau. Sử dụng các thành phần cận biên, nhiệt độ tối đa / tối thiểu / dao động, độ ẩm khác nhau, nguồn điện bẩn, môi trường rf ồn ào, vv trong một khoảng thời gian mô phỏng thời gian sử dụng bình thường lâu hơn nhiều. Hệ thống sẽ có những thất bại thực sự và tỷ lệ thất bại có thể được tính toán.

Lỗi rất có thể là lỗi firmware. Tất cả mọi thứ tôi đã làm đã có một vài.

Hãy chắc chắn rằng bạn đã bật đồng hồ bấm giờ và yêu cầu tất cả các chức năng lặp lại quan trọng xảy ra trước khi "vuốt ve chú chó". Tôi thích đặt cờ trong ngắt hẹn giờ và sử dụng nó để xóa cơ quan giám sát trong vòng lặp chính.

Kiểm tra phục hồi firmware của bạn qua các chu kỳ thiết lập lại quá.

Vì khởi động là khi có rất nhiều thất bại xảy ra, tôi thích cấp nguồn thông qua rơle, sau đó viết một kịch bản nhanh vào chu kỳ điện, chờ cho đài phát thanh báo thức, lặp lại. Sau đó làm điều này trong 10000 chu kỳ hoặc hơn.

Một vài điều hiển nhiên:

• Thất bại pin. Có thể mất chất điện giải dẫn đến ô nhiễm thiết bị điện tử
• Quá điện áp từ hệ thống PV
• Nó đang di chuyển hoặc gần máy móc? Sau đó sốc / rung
• Mất liên lạc do môi trường bên ngoài (mưa / tuyết hấp thụ tín hiệu, v.v.).

Nếu bạn đang thực hiện FMEA, trước tiên bạn cần xem xét mức độ nghiêm trọng của hệ thống trước khi bạn có thể quyết định điều gì cấu thành lỗi.

Tôi ngạc nhiên khi không ai nhắc đến Thử nghiệm cuộc sống tăng tốc và Thử nghiệm cuộc sống tăng tốc cao .

Một trong những công cụ quan trọng mà bạn có theo ý của mình là cứ sau 10 độ tăng nhiệt độ, độ tin cậy trung bình sẽ giảm 50%. Bạn có thể có được một số ý tưởng về tuổi thọ của sản phẩm bằng cách thử nghiệm nó ở nhiệt độ tăng lên rất nhiều. Bạn không phải kiểm tra các thành phần vượt quá nhiệt độ định mức của chúng để tận dụng lợi thế này.