大規模な組み込みプロジェクトをどのように構成しますか？[閉まっている]

背景：

ジュニアR＆Dエレクトロニクスエンジニア（社内唯一のEE）-ハードウェアとコーディングは問題ではありません。私の最大の問題は、プロジェクトの適切な概要を取得し、どこから始めるかです。

これまでのところ、マイナーなソフトウェアプロジェクト（500行未満のコード）しか作成していませんが、機能の概要や機能の欠如を失うことなく、より大きなプロジェクトを行うことは想像できません。

大規模な組み込みソフトウェアシステムを構築するには、どのように最適な構造/どのツールを使用しますか？

私が現在していること：

私は通常、プロジェクトの機能をスケッチすることから始めます。1対多の階層化されたフローチャートまたは関連図（ブロック図など）で、コンポーネント/チップの調査を行う場合があります。次に、データシート/インターネットを参照し、一度に1つの機能をコーディングし、ダミーデータでテストするか、同様のテストをしながら、コーディングに直行します（フェイルファースト）。MEMチップにデータを書き込んでいる可能性があり、それが機能する場合、メインチップとMEMチップ間のSPIドライバーである可能性があります。

私が探している答えは何ですか：

本当に何でも。私が賢明だと思うものを整理します。本、記事、個人的な経験、推奨事項などです。

高齢者がどのようにこれに取り組んでいるかを知りたいです。

編集

まず、長年の経験を共有していただきありがとうございます！すべての答えは大歓迎です。これからの私の見解は次のとおりです。

• 明確で正確な仕様書を作成します。
• ソフトウェア設計文書を作成します。（これから追加するもの） ドキュメントテンプレートのデザイン
• モジュールの中で、どれほど冗長に見えるかを考えてください。（もっと集中する必要があるもの）
• ヘッダー/ソースファイルを構造化するためのコーディング標準に従ってください。（これを行わなかった） Barr Group C標準
• 最初に低レベルの実装を作成することに焦点を合わせます。（通信など）
• 可能な限り/賢明な設計パターンを実装します。 デザインパターン
• リビジョン管理のために何かを設定します（Githubなど-あまり使用しません）
• 継続的インテグレーション/継続的展開の研究（何か新しいことにつまずいた） CIとCDの基本

プロジェクトの構造化に必要な詳細度に影響するいくつかの側面があります。私にとって、主な要因の1つは、私がコーディングを1つだけであるか（あなたが書いている限りあなたが唯一のEEであるように思われること）、または他の人が関与するかどうかです。次に、「大」が実際に何を意味するのかという疑問があります。通常、設計プロセスは次のステップに分けられます。

要件の定義 適切なソフトウェア仕様を取得して、多くの計画を処理することが既に完了している場合。あいまいな要件を取得した場合、最初に行う必要があるのは、顧客が実際に望んでいることを整理することです（場合によっては、顧客が実際に知らないこともあります）。すぐにコーディングに飛びつくのは魅力的だと思いますが、それはそもそも明らかではないかもしれず、開発の途中でコードに簡単に絞り込めない重要な機能を失うリスクをもたらします。

システムの境界と保守性 組み込みシステムでは、いくつかのシステムインターフェイスがあり、一部は外部（オペレーター）に、また内部にもあります。これらを適切に定義し、依存関係を可能な限り低く保つようにしてください。これにより、継続的なエンジニアリングと保守性が簡素化されます。また、必要に応じてコードをコメント/ドキュメント化します。他の誰がそれを使用する必要があるかは決してわかりません。

検証可能なタスクを定義する 特に他の開発者が同じコードベースで作業している場合、明確なタスク（機能）とそれらの間の必要なインターフェイスを定義することは避けられません。可能であれば、個々の機能を他の機能から独立してテスト/検証する必要があります。テストケースを定義できるように、インターフェイスを適切に定義する必要があります。

次々と機能 人よりも進歩を好むため、さまざまなタスクがある場合、彼らは通常、ほとんどの進歩を約束するものに取り組みます。私は通常、次のタスクを開始する前に、タスクを終了して検証済みのテスト済みの状態にすることを試みます。これにより、コードを他の人がテストでき、何かを忘れることがなくなります。

リビジョン管理 プロジェクトの存続中に、新しいバージョンで導入されたバグを特定したり、3年前に出荷したデバイスとまったく同じように動作するデバイスを構築したりするために、古いバージョンが必要になる場合があります。コードに明確なビルドリビジョンとタグがあることを確認してください。Gitは間違いなくあなたの友達です。

Humpawumpaはすばらしい答えを書きました！私は彼のポイントのいくつかを補足したいだけですが、これはコメントには長すぎるので、別の答えを書きます。

私はかつてOPの地位にいました-唯一のEEではなく、小さな会社でMCU開発を行った唯一のEEです。

あなたが唯一の開発者であっても、モジュール性の重要性を十分に強調することはできません。プロジェクトの成長に合わせて正気を保つ唯一の方法です。それぞれ1つの機能概念のみを処理するモジュールの作成に厳格であり、外部インターフェースを可能な限り最小限に抑える必要があります。高レベルモジュールは機能要件に対応し、低レベルモジュールはハードウェアリソース（デバイスドライバーなど）と密接な関係があります。

さまざまなモジュールが情報を共有する方法を正確に示した詳細なデータフロー図^1を維持するのに多くの時間を費やしました。一部の機能には、リアルタイムパフォーマンスの点で非常に異なる要件があります。情報共有がそれにどのように影響するかを必ず確認してください。図には、さまざまな割り込み駆動型ドメインから非割り込みコードを分離する境界が描かれていました。

¹ 制御フローに焦点を当てたフローチャートとは大きく異なります。

大規模なプロジェクトの場合、自分ですべてを行うつもりであっても、複数の開発者が関与しているかのように計画します。

理由は簡単です：

1複雑さ。大規模なプロジェクトには常に複雑さが伴います。複数のチームが関与しているかのようにプロジェクトを計画したということは、複雑さが考慮され文書化されたことを意味します。大規模なプロジェクトで問題が発生するのを見た回数は多く、通常は何かが「ひび割れた」ためです。箱のサイズだけでなく、機械的な組み立ても考慮する必要があることを忘れないでください。ヒートシンクが必要になりますか？安全のために箱を接地する必要がありますか？このカテゴリだけでも多くの質問があります。

2要件。複数の人が関与していると仮定すると、最上位の要件（不必要な複雑さとコストをもたらす可能性があるため、私はしばしば挑戦します）をさまざまなより小さく必要な達成可能なタスク（より大きな組織の別のチームに与えることができる）に分解する必要があります）1つのblobを見るだけではありません。

3パーティション。パーティショニングには2つの主要なタイプがあります。ハードウェア機能とハードウェア/ソフトウェア。最初のタイプは、どの別個の（ただし通信する）機能ブロックが存在する必要があるかを判別することです。2つ目は、より単純な（場合によっては）ハードウェアとソフトウェアのトレードオフですが、単により多くのものをソフトウェアに移しても、必ずしもハードウェアの問題が解決されるわけではないことに留意してください。実際にソフトウェアに移行すると、状況によってはハードウェアの複雑さが大幅に増加する可能性があります（処理能力、インターフェイスの複雑さなど）。

4つのインターフェース。パーティション分割プロセスは、内部インターフェイスの定義に役立ちます。通常、外部インターフェイスは全体的な要件の一部です（常にではありません）。あり、多くは、システムのさまざまな部分が連携するための方法ますが、これは複雑な通信プロトコルや、単に良い/悪いシグナリングです。

5検証。これは、低レベルのテスト（ハードウェアおよびドライバー用）とシステムレベルの混合です。プロジェクトを明確に定義されたブロックで実行すると、堅牢な検証が可能になります（分析または実際のテストによる場合があり、通常2つが混在します。設計の更新では類似性の引数を使用できます）。

6標準。私は、より大きなチームであるかのようにコーディングと描画の標準を使用しています。Barrグループのコーディング標準を使用するのは、面倒ではありませんが、多くのクラスのバグがコードに含まれないようにするためです。PCB出力ドキュメントについては、IPC-D-326（IPC-D-325を呼び出します）に従います。これは、私の意図をPCB製作者とアセンブラーに伝える実証済みの方法です。これは奇妙に思えるかもしれませんが、いくつかの標準に従う規律があることは、品質が一貫していることを意味します。

7バージョン管理。すべてにリビジョン管理を使用しますプロジェクトの部分（システム、ハードウェア、ソフトウェア、機械、テスト要件-すべて）に。私が使用するCADツールは、すべてのソフトウェアおよびFPGAビルドツールと同様に、バージョン管理をサポートしています。

私は多くの組み込みプロジェクトに取り組んでおり（多くの経験豊富な人々がここにいます）、チームの規模は1（私自身）から数十（または特定のプロジェクトセットで数百）までさまざまであり、時には地理的に離れた場所に広がっていますサイト。同じ機能を備えた（動作することがわかっている）アプローチを使用すると、特定のタスクを比較的分離してピックアップし、完了して、より大きなプロジェクトのスタンドアロン部分として徹底的にテストできます。また、必要に応じていくつかのことをサブスクライブできることも意味します。

これらすべてのことを行うと、事前の時間が少しかかりますが、最終的には複雑な組み込みシステムの高速ルートになります。

他の答えは多くの素晴らしいヒントを与えます。組み込み開発のキャリアで私が最も重要だと感じた2つを以下に示します。

1. 可能な限り多くのコードを、明確に定義された独立したモジュールにします。
2. モジュールをPCで自動的にテスト可能にします。

それは、組み込みシステムで「継続的統合」スタイルの開発を行うために必要なものです。自動テストのためにハードウェアに緊密に結び付けられたコードが常に存在しますが、最小化するようにしてください。シミュレートされたデータまたは実際のハードウェアからのデータキャプチャを使用して、テストシステムにフィードすることで、かなり遠くまで到達できます。

既存の回答に追加するには...

私はいつもボトムアップから始めます。ハードウェア設計から、I / Oが何であるかがわかります。そのI / Oをカプセル化するドライバーモジュールを構築することから始めます。これにより、高レベルのコードが低レベルのものについてあまり知る必要がなくなります。

低レベルのインターフェイスを構築する場合、もちろんテストハーネスが必要です。これを最初からPCに接続するように設計すると（おそらくRS-232ポート、おそらくUSB、おそらくイーサネット経由のtelnetを使用）、アプリケーションの構築中にこのテストハーネスインターフェイスを維持できます。アプリケーションの形に合わせてテストハーネスフックを追加し続けることができます。これにより、コードのリグレッションテストを実行することもできます。

私は4つの質問で考える傾向があります。最初の2つはシステムプロジェクトの開始に属し、2つは最後に向かっています。

1. 彼らは実際にシステムを望んでいますか？システムは、顧客が受け入れる時間とコストの規模で顧客の問題を解決しますか？一般的な問題は、顧客が使用しないシステムの構築です。

2. そのシステムを実際に構築できますか？おそらく、必要なパフォーマンス、精度、電力使用量を提供することでしょうか？

初期のプロトタイプを作成することは、これら2つの最初の質問に答えるための良い方法です。リスク軽減は初期段階で非常に重要です。

次の2つの質問は、プロジェクトの後半の段階を対象としています。

3. 実際に終わりましたか？設計、コーディング、テスト、提供されたすべてのもの

4. 彼らは実際にシステムを使用していますか？