rhapsody - DO-178アビオニクス環境のラプソディ？

Question

DO-178アビオニクス環境でRhapsodyを使用した人はいますか？つまり、FAA / DERプロセスと連携して、アーティファクトを提供し、承認してもらいます。Rhapsodyは認定可能なMDDツールではないことを理解しているので、他の緩和要因があるかどうか興味がありました。

成功した場合、これを達成するためにどのような手順を実行しましたか？

フィードバックと洞察をありがとう。

Answer 1

私は、DO-178B レベル D に準拠して開発された (しかし認定されていない) プロジェクトで Rhapsody を使用しました。要件は DOORS で管理され、Rhapsody Gateway ツールを使用して Rhapsody にリンクされました。トレーサビリティは 178B の重要な部分であるため、これは重要でした。

ソフトウェアは Rhapsody でモデル化され、コードは手動で生成されました。コードの自動生成では、Rhapsody が 178B に準拠する開発ツールとして認定される必要があるため、手動のコード生成が選択されました。IBM が Rhapsody に対して 178B 認定を提供しているかどうかはわかりません。

要件に対するソフトウェアの検証は、特注のテスト ツールを使用して実行されました。このため、検証ツールとしての資格を得るために、ツールのいくつかの重要なテストを実行する必要がありました。

作業している 178B のレベル、使用している/使用する予定のツール (Rhapsody 以外)、またはコードを自動生成するかどうかに関する情報が含まれていないため、質問に答えるのは非常に困難です。等

これが役立つことを願っています。

Answer 2

DO-178B レベル A/B 準拠のプロジェクトで Rhapsody C++ を使用した経験があります。

自動生成されたコードは、適切なレベルの MC/DC カバレッジを含むカバレッジ要件に従って検証されます。生成されたコードは、厳密な静的/動的テストと手動レビューによって完全に検証されているため、手作業でコーディングされているかのように、Rhapsody ツールの認定は必須ではありませんでした。

Rhapsody コード生成プロパティーをカスタマイズして、ctor/dtors や get/setter などの必要なコードのみを生成し、決定論的でないライブラリー関数や動的メモリー割り当てを伴うライブラリー関数を回避することに多大な努力を払いました。

モデルにはすべてのコードが含まれているため、コードではなく Rhapsody モデル ファイルがバージョン管理されるように、ラウンドトリップ エンジニアリングを十分に活用することができました。

Rhapsody UML は、再利用可能で移植可能なソフトウェア・アーキテクチャーを開発するために検討する必要があります。