Part Insights Experience

Access critical supply chain intelligence as you design.

Cloud Storage and Version Control

Store your libraries and design data in one secure, accessible, and version-controlled space.

Variant Manager

Meet demands of a globalized market that requires unique versions of your PCBs.

Filter
Clear
Tags by Type
Popular Topics
Software
マルチCADエンジニアリングの主な課題のカバー写真 マルチCADエンジニアリング:トップ6の課題 理想的なシナリオでは、すべてのエンジニア、製造業者、請負業者、および顧客が同じCADシステムを利用し、協力作業を大幅に簡素化します。しかし、製品設計の現実はこの理想からは程遠いものです。様々な企業が異なるECADシステムを選択しており、これを電子製品開発の一部として受け入れる必要があります。 たとえ一つの組織内であっても、異なる部門や事業部が物理的な近さに関係なく、異なる設計ソフトウェアを使用しているのが一般的です。この多様性は、エラー、無秩序、非効率、努力の重複、および財務上の損失を含む多くの課題を引き起こします。しかし、なぜこのような状況が発生するのでしょうか? マルチCAD環境の理由 レガシーデザイン まず、多くの組織が主要なCADツールを操作しながらも、複数のCADシステムで作成されたレガシーデザインの範囲を保持しています。これらの古いデザインは依然として関連性があり、実際のアプリケーションや進行中のプロジェクトに合わせて更新または修正が必要な場合がよくあります。最近の ウェビナーのアンケートでは、回答者の51%以上がレガシープロジェクトが複数のECADツールを維持する理由であると述べています。 回答者の51%以上がレガシープロジェクトが複数のECADツールを維持する理由であると述べています。 分散型ECADツール選択 次に、各チームにCADツールを選択する自律性が与えられている分散型チームを持つ組織に遭遇することがあります。この多様性は、新しく統合された企業が確立されたワークフローと慣行を維持したいと望む過去の買収からしばしば生じます。 さらに、特定のチームは、組織の主要なオプションよりも特定のCADツールを使用することを好むかもしれません。それは、慣れ親しんでいるため、効率が良いため、または他のソフトウェアやシステムとのカスタム統合を開発しているためです。異なるCADツールに切り替えると、これらの特別なソリューションを失うか、ワークフローを再構成する際に重大な障害に直面する可能性があります。 実際、 調査された人々の40%以上が少なくとも毎月二次ECADツールを使用しており、わずか16%以上が単一のECADツールにのみ依存していると報告しています。 回答者の40%以上が少なくとも毎月二次ECADツールを使用しており、約16%だけが単一のECADツールに完全に依存していると報告しています。 設計請負業者と製造業者 最後に、設計請負業者と契約メーカーの役割を見過ごすことはできません。これらの外部パートナーは、クライアントの仕様、推奨事項、および好みに合わせるために、複数のCADシステムに精通してクライアントの範囲を越えて作業します。 マルチCADエンジニアリングの課題 しかし、マルチCAD環境の背後にある理由を理解することは、始まりに過ぎません。これらの多様なシステムは、プラットフォーム間のECAD管理とコラボレーションを大幅に複雑にし、その理由はこちらです。 #1 ファイルの非互換性 異なるCADシステムは通常、独自のデータ形式を使用しており、プラットフォーム間でファイルを共有する際に互換性の問題が生じます。多くのCADツールは、他のシステムのファイルを自分の形式に適応させるファイルコンバーターを提供していますが、これらのコンバーターは特に複雑な設計の場合、完璧ではありません。変換プロセス自体が、データの損失、破損、またはエラーなどの問題を引き起こし、設計の完全性に深刻な影響を与える可能性があります。
アジャイル・ハードウェア開発 カバー写真 原則が健全である理由、しかし戦術は再考が必要である 私たちの「アジャイルを解明する」シリーズの最終回では、ハードウェア開発がアジャイル手法と交差する複雑な風景をナビゲートします。アジャイルの基本原則は確かな基盤を提供しますが、 電子ハードウェアのユニークな課題に適用される場合、戦術の再評価が不可欠になります。探求の旅で、アジャイルの共通の要素と儀式を解き明かし、それらを具体的な製品開発の文脈で変革する方法を探ります。 アジャイルマインドセットを採用し、一貫して育むことから始める ハードウェア開発における日々のソフトウェアアジャイル実践を強力な利点に高めるための戦術的調整に深く潜る前に、アジャイルマインドセットの基本的な原則をまず受け入れることが重要です。良いスタート地点は、 アジャイル宣言の意図を考慮し、ハードウェア開発のニーズに合わせて言語を修正することかもしれません。以下の表は、ハードウェア開発のための一つの潜在的な宣言を提供します。 各マニフェストの意図の簡単な要約は、 「協力して反復的な開発と学習のアプローチを用い、顧客が本当に価値を見出すものを発見し、提供しましょう。」となるでしょう。もちろん、これはほぼすべてのプロジェクトにとって理にかなっており、チームが日々の開発戦術に没頭する中で、これらの基本的な原則を念頭に置くことが重要です。 方向性計画の重要な役割 アジャイルの反復的な性質は、時に初期計画が後回しにされ、とにかく始めることに重点が置かれるような印象を与えることがあります。しかし、物理的および電子製品の設計と開発の複雑なプロセスをナビゲートするためには、ある程度の事前計画が不可欠です。徹底的な事前計画ではなく、反復的な学習と実行を通じてチームを開発の旅に導くロードマップと考えてください。 アジャイルハードウェア開発の初期計画には、明確な目標の設定、マイルストーンの定義、そして熟考されたプロトタイピングと フィードバック戦略を通じたリスク評価の軽減が含まれます。これにより、チームはアジャイルの適応性と成功したハードウェア開発に必要な構造化された計画の間のバランスを取ることができます。 ユーザーストーリーと作業項目の分離 このシリーズの前の記事で議論したように、 アジャイル「専門家」はしばしば、ハードウェアチームにタスクを定義するためにバックログをユーザーストーリーで埋めるよう促します。ハードウェアのユーザーストーリーを考えてみましょう。新しいフォークリフトの開発を計画していると仮定します。次のようなユーザーストーリーを書きます: "ユーザーとして、素材をすぐに取り出せるようにしたいので、在庫の移動にかかる時間を節約できます。" ハードウェア開発者は何をすべきか知っていますか?おそらく知りません。解決すべき問題の側面が多すぎます。実装には、フォークリフトの速度、フォークアタッチメントの精度、インテリジェントな在庫感知、在庫の向き、その他多くの要因が関わるかもしれません。これらのユーザーストーリーは、具体的な機能やタスクではなく、 製品要件や作業項目というよりも、顧客の目標になるべきです。 ユーザーストーリーは、アジャイルなハードウェア設計フローにおいて、顧客のニーズに焦点を当て、顧客が達成しようとしている結果を明確にするための場所があります。しかし、物理製品のユーザーストーリーは直接的に機能、属性、またはタスクに翻訳できないため、それらはタスクバックログを開発するための出発点となり、バックログアイテム自体にはなりません。 実証可能な進捗と成功のためのプロトタイピング戦略 計算されたプロトタイピングは、ハードウェア開発における要であり、その重要性は過大評価できません。アジャイルの伝道師は、迅速なソフトウェアリリースの美徳を説きますが、ハードウェアの領域では、