とあるリアルタイムOSについて

**仕様書無しさん** · 2025/06/23(月) 14:23:11.96

・μITRON4.0仕様から逸脱している独自仕様も結構あるのに、自前の仕様書を用意していない
・文書類がサーバのどこにあるのか、周知されていない。というより、管理されていない
・ソース・ファイルをSVNやGitなどの版数管理ソフトで管理していないため、どのソースが最新なのか、社員間で共有されていない。容易に、破棄されたはずの古いソース・コードを誤って使用する事例が起こる。というか、よく起こっていた
・レビュー結果報告書とか作っていない。というか、レビューの指摘→結果反映→反映に対する指摘を思いつきで行う→結果反映・・・をメール・ベースで延々と繰り返す、不毛な作業をレビューと呼んでいる。いつまでたっても"レビュー"が終わらない
・テスト仕様、テスト項目が存在しないか、または社員に周知されていない。したがって、テストの実行者もOSのどの機能がテストされているのか把握していない。当然、テスト結果報告書とかも作られていない
・新しいCPUにOSを移植する際、Cソース部は「ロジックの妥当性は他のCPUでかくにんされているから」との理由でまともにテストしていない。コンパイラの解釈により、不具合事象が発生する可能性を完全に無視している
・文書、ソース、テストが適当な管理のため、当然トレーサビリティなど意識されていない。また、不具合が出ても、不具合を出した時点の環境を再現できないので、原因究明が困難
・この程度の管理にもかかわらず、医療機器ではクラスIIIとかに使われている
・車載系でも使っている向きがあるようだが、当然機能安全とかは意識していない

今現在どうなっているのかは知らないが、少なくとも吾輩が関わっていた頃はこういう管理体制だった。

「この程度、普通じゃないか」と感じる方は半分より多いのか、少ないのか・・・、世間一般の感覚が良くわからないので、ぜひ聞いてみたいです。

**親バカ** · 2025/06/23(月) 19:10:24.17

μITRONに逸脱してるとかいうけど、逸脱してないのはTOPPERS/JSPぐらいなものです。
だいたいμITRONであるか否かの基準がゆるゆるなのでまぁ普通にμITRONと名乗っていいことになってる。
あと具体的に実装による部分については

実装依存
実装定義
の２分類になるが実装定義が望ましいが実装依存である場合もある。
実装依存は必ず決まった動作にならないことを含むから、そういうのも許容されてるよ。

長文だったので第1項のみレスした。