エレクトロニクス設計のコラボレーション

現代の電子製品を作成するには、複数の分野や専門家間での協力が必要です。チームメンバーや顧客と協力するための最高の電子設計ソフトウェアの使用についてもっと学ぶために、私たちのリソースライブラリをご覧ください。

Filter
見つかりました
Sort by
役割
ソフトウェア
コンテンツタイプ
適用
フィルターをクリア
クラウドコラボレーションで電子機器のライフサイクルを管理しましょう クラウドコラボレーションで電子機器のライフサイクルを管理しましょう 1 min Blog 電子製品のライフサイクルは、コンポーネントのライフサイクルに大きく依存しているという点で興味深いものです。この関係にもかかわらず、すべての電子製品のライフサイクルは他の製品と同様の軌道をたどります。新製品は初期採用から始まり、後に持続的な成長を経てピーク採用に達し、より優れた機能を持つ新製品が登場すると徐々に衰退します。この事実を受け入れると、各フェーズの電子製品ライフサイクルを利用して、設計とビジネス戦略を計画する方法を決定できます。 もしチームが新製品に取り組んでおり、製品のライフサイクルをコントロールしたい場合、2種類のライフサイクルの可視性が必要です:完全なサプライチェーン情報と製品ライフサイクル管理です。Altium DesignerをAltium 365プラットフォーム上で使用することで、チームは電子製品ライフサイクルの両側面を見ることができます。製品ライフサイクルのこれらの側面についてどのように考え、なぜチームがこの可視性を必要とするかをここで説明します。 電子製品ライフサイクルに何が影響を与えるのか? エレクトロニクスのライフサイクルは、いくつかの理由で短くなっています。エレクトロニクスにおいて、製品のライフサイクルは部分的にはその機能を実現するコンポーネントのライフサイクルに依存します。製品の寿命を通じて長いライフサイクルと再設計の回数を少なくすることを望む設計チームは、NRNDまたは廃止されたコンポーネントの原因を理解しています。これはビジネス上の問題でもあります:製品がコンポーネントの廃止とは無関係な理由で突然廃止されることがあります。 急速な技術開発と消費者の注意が短くなるこれらの日々において、任意の製品のエレクトロニクスのライフサイクルを予測することは難しくなります。ここでは、電子製品のライフサイクルに影響を与える要因のいくつかを紹介します: 消費者の需要。これはビジネス上の問題であると同時に設計上の問題でもあります。消費者の好みは時間とともに変化します。 競合製品のリリース。競合が市場シェアを脅かす製品をリリースすると、あなたの設計は適応する必要があります。これはハードウェアレベルでの変更を強いるかもしれず、再設計を引き起こす可能性があります。 コンポーネントの廃止。製品のコンポーネントがNRND廃止された場合、製品を大規模に生産し続けるためには製品を更新する必要があります。または、完全に新しい製品に置き換えるべきです。 新しいコンポーネントはより多くの機能を提供します。この点と前述の陳腐化に関する点は相互に排他的ではありません。しかし、コアコンポーネントの新しいバージョンが利用可能になると、設計中の現行コンポーネントが陳腐化するリスクが高まります。新しいバージョンが利用可能であれば、コンポーネントがNRND(新規設計非推奨)になる可能性がありますが、完全に廃止される前に生産が続けられることもあります。 下の画像では、進行中のプロジェクトの最近のリビジョンに対してActiveBOMドキュメントを開きました。設計プロセスの早い段階でサプライチェーンを確認しなかったため、在庫切れのコンポーネントやいくつかの陳腐化したコンポーネントを交換する必要がありました。デザイナーは、すでにシンボルとフットプリントを持っていた信頼できるコンポーネントに固執しました。幸いにも、これらの陳腐化したコンポーネント(下のショットキーダイオードを参照)はすべて標準的なパッケージングを持っていたので、再設計は迅速に進みました。もっと悪い状況になり得ました;中心的なSoCが陳腐化していた場合、私たちは(ボードとファームウェアのレベルで)大幅な再設計に直面していたでしょう。 このデバイスの長期ライフサイクルは短く、NRNDおよび陳腐化したコンポーネントが含まれています。製品を繰り返しリリースする場合、設計チームはその寿命を延ばすために代替コンポーネントを選択する必要があります。 この製品の再設計はどの程度広範囲にわたる必要がありますか?これはオープンな質問です。標準パッケージの受動部品のような単純なコンポーネントの場合、再設計はそれほど広範囲には及びません。熟練した設計者であれば、これらを比較的迅速に実装できます。SMD受動部品は標準パッケージで提供される傾向があるため、回路図とPCBレイアウトで代替コンポーネントを簡単に交換することができます。ICやSoCの場合、デバイスにコンパイルする任意のコードの前方互換性をコンポーネントメーカーに依存しなければならないため、巨大なリスクを負うことになります。コンポーネントがもはや調達できなくなるまで待つのではなく、適切な代替品に今すぐ交換する方が良いでしょう。 特殊なIC、特殊なSoC、センサー、またはその他のコンポーネントを備えた組み込みシステムの場合、必要とされる再設計はより広範囲に及び、製品のファームウェアにまで及ぶことがあります。標準的なIP(例えば、Arm Cortexコアで動作するMCU)を使用するよく知られたベンダーを選択している場合、ファームウェア開発に必要なライブラリは小さな変更で済むため、再設計や開発作業の範囲が縮小されます。 クラウドで電子機器のライフサイクルを管理する チームの全員が早期にコンポーネントのライフサイクル情報にアクセスでき、設計のライフサイクルステータスを追跡できるようにすることで、リデザインを予測する管理プロセスを作成できます。これは、適切なクラウド協業ツールを使用して、設計データをチーム全員と共有することにかかっています。 チーム全員が製品およびコンポーネントのライフサイクルの可視性を必要とする場合は、Altium 365上のAltium 記事を読む
ハードウェア・イン・ザ・ループテスト:イントロダクション ハードウェア・イン・ザ・ループテスト:イントロダクション 1 min Thought Leadership 「ハードウェア・イン・ザ・ループ」テストを検索すると、複雑なリアルタイムシステムの例が頻繁に見つかります。 例えば、このNational Instrumentsの記事は、ハードウェア・イン・ザ・ループ(HIL)が何であるか、そして自動車内の電子制御ユニットのテストの例を提供している上で、素晴らしい説明と背景を提供しています。この記事では、HILテストコンセプトのより小さく、より取り組みやすいバージョンに焦点を当てます。 ハードウェア・イン・ザ・ループテストとは何か? この記事の目的のために、我々はハードウェア・イン・ザ・ループテストを従来提示される方法(例えば、自動車アプリケーション内で)とは少し異なる方法で定義します。製品をテストする際の複雑さの異なる三つのレイヤーを観察しましょう。 テストフォーマット1:基本的な手動テスト このテスト形式では、エンジニアがデバイスを手動でテストします。これには、デジタルマルチメーターで基板上のテストポイントを探る、オシロスコープで波形を観察する、またはコンピューター画面上でテレメトリー読み取りを手動で解析することが含まれます。エンジニアは、手動の設計検証テストを通じて製品をテストします。 テストフォーマット2:自動テスト このテストセットアップは、通常エンジニアによって行われる同じ測定と検証を実行しますが、コンピュータによって自動化された方法で実行されます。ホストコンピュータは直接計測器(例:マルチメーター、オシロスコープなど)に命令を出し、デバイスからのテレメトリを解析し、その後、エンジニアによって設定された基準に基づいてテストセットを検証します。 テストフォーマット3:ハードウェア・イン・ザ・ループテスト ハードウェア・イン・ザ・ループテストは、実世界のアプリケーションをシミュレートする追加の刺激を加えることで、自動テストを新たなレベルに引き上げます。例えば、テスト対象のデバイス(DUT)には、刺激が必要な一連のセンサーがあるかもしれません。テスト機器は、それらのセンサーの他端をシミュレートして、DUTのセンサー側を刺激します。別の例としては、DUT上のRS-422レシーバーにRS-422トラフィックを駆動することが挙げられます。私たちがDUTに新しい刺激を駆動し、ホストコンピュータからテレメトリを読み取り、必要に応じてテストを適切に調整できる(例:初期テストを通過した後に、より速く、より多くのRS-422トラフィックを駆動する)という考えです。 ハードウェア・イン・ザ・ループを採用する利点 アプリケーションに基づいて、なぜハードウェア・イン・ザ・ループ(HIL)テストを自動テスト(そしてもちろん手動テスト)よりも採用するかが明確になる場合があります。複雑なシステム、または(システムのシステム)を統合しようとしている場合、多くの外部刺激が必要であれば、基本的な自動チェックアウトテストでは不十分です。基本的なバッテリーチャージャーを考えてみましょう。電源、負荷、バッテリーをシミュレートしてコントローラ回路をテストすることはできますが(物理的にもソフトウェアを通じても)、実際の電源、バッテリー、負荷を使用して設計をテストする方が現実的です。さらに、このプロセスを自動化できれば、エンジニアはテストよりも開発に時間を費やすことができます。 コスト分析:それは価値がありますか? ハードウェア・イン・ザ・ループテストを採用するかどうかを決定する際には、次の要因を考慮する必要があります: テスト時間:デバイスのテストにどれくらいの時間を費やす予定ですか?基本的なチェックアウトを行って終わりですか、それとも数ヶ月のテストが必要ですか? テストの再発生:同じテストをどれくらいの頻度で実行しますか?このテストセットアップ(つまり、機器と自動化スクリプト)は将来の設計に使用できますか? テスト機器:自動テストと手動テストに必要な機器を揃えるコストはどのくらいかかりますか? これらおよびその他の要因を考慮したら、手動テストを続けるか、自動/ハードウェア・イン・ザ・ループテストに投資するかの決定を始めることができます。 始め方 記事を読む