エレクトロニクスを設計する世界

サイロを崩壊させ、エレクトロニクス開発のあらゆる側面での協力を強化する

詳細を見る

Altium 365 - エレクトロニクス設計エコシステム

マルチ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ツールは、他のシステムのファイルを自分の形式に適応させるファイルコンバーターを提供していますが、これらのコンバーターは特に複雑な設計の場合、完璧ではありません。変換プロセス自体が、データの損失、破損、またはエラーなどの問題を引き起こし、設計の完全性に深刻な影響を与える可能性があります。

アジャイル・ハードウェア開発カバー写真

原則が健全である理由、しかし戦術は再考が必要である私たちの「アジャイルを解明する」シリーズの最終回では、ハードウェア開発がアジャイル手法と交差する複雑な風景をナビゲートします。アジャイルの基本原則は確かな基盤を提供しますが、電子ハードウェアのユニークな課題に適用される場合、戦術の再評価が不可欠になります。探求の旅で、アジャイルの共通の要素と儀式を解き明かし、それらを具体的な製品開発の文脈で変革する方法を探ります。アジャイルマインドセットを採用し、一貫して育むことから始めるハードウェア開発における日々のソフトウェアアジャイル実践を強力な利点に高めるための戦術的調整に深く潜る前に、アジャイルマインドセットの基本的な原則をまず受け入れることが重要です。良いスタート地点は、アジャイル宣言の意図を考慮し、ハードウェア開発のニーズに合わせて言語を修正することかもしれません。以下の表は、ハードウェア開発のための一つの潜在的な宣言を提供します。各マニフェストの意図の簡単な要約は、「協力して反復的な開発と学習のアプローチを用い、顧客が本当に価値を見出すものを発見し、提供しましょう。」となるでしょう。もちろん、これはほぼすべてのプロジェクトにとって理にかなっており、チームが日々の開発戦術に没頭する中で、これらの基本的な原則を念頭に置くことが重要です。方向性計画の重要な役割アジャイルの反復的な性質は、時に初期計画が後回しにされ、とにかく始めることに重点が置かれるような印象を与えることがあります。しかし、物理的および電子製品の設計と開発の複雑なプロセスをナビゲートするためには、ある程度の事前計画が不可欠です。徹底的な事前計画ではなく、反復的な学習と実行を通じてチームを開発の旅に導くロードマップと考えてください。アジャイルハードウェア開発の初期計画には、明確な目標の設定、マイルストーンの定義、そして熟考されたプロトタイピングとフィードバック戦略を通じたリスク評価の軽減が含まれます。これにより、チームはアジャイルの適応性と成功したハードウェア開発に必要な構造化された計画の間のバランスを取ることができます。ユーザーストーリーと作業項目の分離このシリーズの前の記事で議論したように、アジャイル「専門家」はしばしば、ハードウェアチームにタスクを定義するためにバックログをユーザーストーリーで埋めるよう促します。ハードウェアのユーザーストーリーを考えてみましょう。新しいフォークリフトの開発を計画していると仮定します。次のようなユーザーストーリーを書きます： "ユーザーとして、素材をすぐに取り出せるようにしたいので、在庫の移動にかかる時間を節約できます。" ハードウェア開発者は何をすべきか知っていますか？おそらく知りません。解決すべき問題の側面が多すぎます。実装には、フォークリフトの速度、フォークアタッチメントの精度、インテリジェントな在庫感知、在庫の向き、その他多くの要因が関わるかもしれません。これらのユーザーストーリーは、具体的な機能やタスクではなく、製品要件や作業項目というよりも、顧客の目標になるべきです。ユーザーストーリーは、アジャイルなハードウェア設計フローにおいて、顧客のニーズに焦点を当て、顧客が達成しようとしている結果を明確にするための場所があります。しかし、物理製品のユーザーストーリーは直接的に機能、属性、またはタスクに翻訳できないため、それらはタスクバックログを開発するための出発点となり、バックログアイテム自体にはなりません。実証可能な進捗と成功のためのプロトタイピング戦略計算されたプロトタイピングは、ハードウェア開発における要であり、その重要性は過大評価できません。アジャイルの伝道師は、迅速なソフトウェアリリースの美徳を説きますが、ハードウェアの領域では、

アジャイル・ハードウェア開発ブログシリーズのカバー

ハードウェア開発がただ…異なる5つの方法電子ハードウェア開発におけるアジャイル手法の実装に伴う独自の課題と戦略を探求します。アジャイルフレームワーク内でのハードウェアとソフトウェア開発の主な違いを理解します。

GovCloud 101 カバーフォト

Altium 365 GovCloud 101: 知っておくべき全てのことデータの保護を強化したいですか？Altium 365 GovCloudがその目標を達成するのに役立ちます。これは、米国政府の厳格な要求に応えるように設計されたAltium 365のバージョンです。

0:24:46 Webinars 同期して最適化：Altium 365のJira統合で効率を向上

プロジェクト管理のために複数のツールを使い分けるのに疲れましたか？ウェビナーをご覧いただき、Jira Integration for Altium 365がどのようにワークフローを最適化できるかを確認してください。

Customer Success Stories SkyShips Discover how Altium Designer and Altium 365 make designing the world's most luxurious automotive infotainment systems a breeze.