Mobile menu
製造
PCB Manufacturing Handoff Tools

Faster design-to-production handoff with your contract manufacturer.

Learn More
Manufacturing Made Easy

Centralize DFM reviews and packages to accelerate PCB production handoff.

Learn More
ホーム 製造

製造

リソースライブラリでは、PCB設計とプリント基板製造の詳細を紹介しています。

Altium's Manufacturing Solutions Guide to Manufacturing with Altium Manufacturing Documentation
Filter
見つかりました
Sort by
役割
ソフトウェア
コンテンツタイプ
適用
フィルターをクリア
Requirements Portal の画像 Requirements Portal 入門チュートリアル 1 min Guide Books PCB設計者 プロジェクトリーダー（マネージャー） 電気技術者 +3 PCB設計者 PCB設計者 プロジェクトリーダー（マネージャー） プロジェクトリーダー（マネージャー） 電気技術者 電気技術者 技術マネージャー 技術マネージャー 機構設計者（メカエンジニア） 機構設計者（メカエンジニア） このチュートリアルでは、Altium Requirements Portal 内で要件を一元化し、接続し、管理する方法をユーザーに案内します。既存データをインポートし、それを設計プロジェクトに直接リンクして、バージョン管理された単一の信頼できる情報源を維持する方法を紹介します。 また、統合されたワークフローによってトレーサビリティが向上し、検証作業が効率化され、プロジェクトの進捗をリアルタイムで可視化できることに加え、コンプライアンスレポートの作成も簡素化される点を強調しています。これらのチュートリアルが、エラーの削減、関係者間の整合性維持、そして設計プロセスにおける明確さと自信の向上にどのように役立つか、ぜひ続きをご覧ください。 記事を読む
SRAMユーザーのためのPCB設計のヒント：データ損失を防ぐ方法 SRAMとは何か？PCB設計のヒントとデータ損失の防止方法 1 min Thought Leadership SRAMは電源が切れるとデータを失います。 編集ソフトウェアの最高の発明の一つは、最悪のタイミングでマーフィーの法則が発動するのを防ぐオートセーブ機能です。数十年前、オートセーブ機能が存在しないことが、「保存」ボタンを押すことを渋っていた私にとって悪化し、重要な大学の課題の数ページが文字通り消去されたとき、私はほとんど泣きました。 電子機器では、SRAMを設計する際の課題を認識していないと、静的ランダムアクセスメモリ（SRAM）に格納されているデータ全体を失うリスクがあります。これは、SRAMが重要な変数を格納している場合、特にハードウェアの予測不可能な動作を引き起こす可能性があります。 SRAMとは何か、そしてどのように機能するのか？ SRAMは、組み込みシステム設計で一般的に使用される不揮発性メモリです。ロジカルビットで情報を格納し、動作電圧が供給されている限りその値を保持します。電源が切断されると、SRAM全体がデフォルト値、通常はロジック1に相当する値にリセットされます。 SRAMの内部は、複数のセルによって構成されています。これらのセルには、いくつかのトランジスタによって制御されるバイステーブルフリップフロップが含まれています。特定のアドレスに情報が格納されると、いくつかのフリップフロップがデータのデジタル値を表すように適切にラッチされます。 SRAMは電源が切れると情報を保持できないにもかかわらず、追加の作業用メモリが必要な設計で定期的に使用されます。FlashやEEPROMなどの他の揮発性メモリコンポーネントと比較して、SRAMは無視できる読み取りアクセス時間を持ち、データはランダムなメモリアドレスに書き込むことができます。 他の電子部品と同様に、SRAMは年々改良されてきました。SRAMが40ピン以上の大型コンポーネントであり、並列アドレスバスがまだ一般的なインターフェースだった時代は過ぎ去りました。今日のメモリメーカーは、 SPIやI2Cのようなシリアルインターフェースを備えたSRAMを生産し、フォームファクターを8ピンまで大幅に削減しています。 SRAMを設計する際の主要な考慮事項 SRAMの設計にさらなる考慮を払うことで、大きな違いが生まれるかもしれません。 SRAMを使った設計は簡単な作業のように思えるかもしれません。結局のところ、ピン数が少ないメモリチップを使った設計が何が難しいのでしょうか？しかし、経験上、実際には多くの問題が発生する可能性があることを学びました。部品選択から製造後の問題に至るまで、多くの問題に遭遇する可能性があります。ここでは、初心者レベルのPCB設計者に役立ついくつかのヒントを紹介します： メモリ容量 最大容量のSRAMを選ぶべきでしょうか？それともプロジェクトの要件に合ったものを選ぶべきでしょうか？これは、ファームウェア開発者を悩ませる質問であり、ハードウェア設計者にとってはそうではありません。メモリメーカーは通常、同じ物理パッケージで異なる容量のSRAMを導入します。これは、メモリ容量の選択が変わっても設計を変更する必要がないことを意味します。 インターフェースタイプ SRAMでよく使用されるインターフェースにはSPIとI2Cがあります。SPIはデータの書き込みと読み出しに4つの物理ピンを必要としますが、I2Cは2つの物理データ接続のみを必要とします。一般に、SPIはより高速なアクセスを提供しますが、SPIバス上の各ICに個別の制御信号が必要です。I2Cは、複数のメモリチップがマイクロコントローラに接続されている場合に理想的で、データ信号とクロック信号のみが必要です。 デカップリングコンデンサ 革新的な不揮発性メモリー、フラッシュや FRAMのようなものが登場している今、バッテリーバックアップSRAMを設計することはほとんどないでしょう。これにより確かにSRAMの設計は容易になりますが、安定した電源供給の重要性を見落としてはいけません。SRAMのVccピンにできるだけ近い場所にデカップリングキャパシタを配置することを常に確認してください。電源の不安定さによるデータの破損は、絶対に避けたい最後の事態です。 デカップリングキャパシタは、グラウンドバウンスの問題を防ぐのにも役立ちます。 記事を読む
Altium 365がPCBアセンブリプロセスをサポートする方法 Altium 365がPCBアセンブリ（PCBA）プロセスをどのようにサポートできるか 1 min Engineering News プロダクションマネージャー プロダクションマネージャー プロダクションマネージャー エンジニアはもはや、ボード組み立てを行う際に紙のプリントアウトをめくったり、CADソフトウェアを操作したりする必要はありません。 記事を読む
Agentic Requirements Engineering のご紹介 エージェント型要件エンジニアリングのご紹介 2 min Blog 技術マネージャー 技術マネージャー 技術マネージャー Agentic Requirements Engineering の登場です。要件ツール上で動作するAIにより、煩雑な作業を減らし、整合性を高め、反復をより迅速に進められます。Requirements Portal でご利用いただけます。 記事を読む
製造性を考慮した設計は部品選定から始まる 表紙 製造性を考慮した設計は、部品選定から始まります 1 min Blog 機構設計者（メカエンジニア） 技術マネージャー 機構設計者（メカエンジニア） 機構設計者（メカエンジニア） 技術マネージャー 技術マネージャー 試作ビルドの2週間前、あるチームは、数か月前に定格電流を理由に選定した基板対電線コネクタが「新規設計非推奨」（NRND）に変更されていたことを知ります。その部品を扱っている唯一のディストリビュータの在庫は、必要数量を下回っており、メーカーの補充納期は40週間との回答でした。最も近い代替品は同じケーブルと嵌合できますが、フットプリントが異なり、高さも約1mm高くなります。 そこで電気設計者はコネクタ周辺を再配線することになります。しかし高くなったハウジングが筐体内のボスと干渉し、機械設計者はそのボスを移動して金型見積もりを取り直さなければならず、結果として試作ビルドのスケジュールは数週間遅延します。 この一連の手戻りは、すべて最初のコネクタ選定にさかのぼります。その部品は単一メーカー製で、選定当時から在庫は薄かったにもかかわらず、電気的仕様だけを基準に採用されました。そしてNRND通知が出るまで、誰も再確認しなかったのです。Design for manufacturability（DFM）は、こうした初期判断に生産要件を織り込み、リリースまで継続して見直せるようにする考え方であり、ほとんどの電子製品では、その判断を機械設計と電気設計が共同で行うことを意味します。 重要なポイント 初期の部品選定、アーキテクチャ、製造方法の選択は、製品コストの主要因を決定づけます。したがって、それらの判断を行う際には生産要件も考慮する必要があります。 部品を最初に選定する際に、ライフサイクル状況、パッケージ、ディストリビュータ在庫を確認し、そのうえで認定済み代替品、または対策計画をBOMに記録しておきましょう。 推奨部品リストによって固有部品を減らし、スタックアップを決める前に、製造業者の対応可能なスタックアップ構成とインピーダンス許容差を入手しておきましょう。 コネクタ選定や部品高さのような共有判断事項は、早い段階で機械設計者と電気設計者が一緒に決めるべきです。 製造コストはどこで決まるのか コスト見積もりに関する研究で昔からよく言われている経験則では、製品コストの約70%は設計初期段階で決まるとされています。『Design for Manufacturability』の著者であるDavid M. Andersonも、予算の観点から同じ傾向を説明しています。すなわち、設計が完了する時点では製品予算のうち実際に使われたのは約8%にすぎない一方で、その時点ですでに約80%のコストが実質的に確定している、というものです。どちらも概算ですが、示している内容は同じです。つまり、コストは早い段階で固定化されるのです。 各プロジェクト段階は、それ以前の判断の積み重ねの上に成り立っています。そのため、問題の発見が遅れるほど、一般に修正コストは高くなります。大規模なハードウェアおよびソフトウェアシステムにおけるエラー修正コストの増大を定量化した NASAの研究では、要求定義段階で1単位のコストで修正できる要求エラーが、設計段階では3～8単位、製造段階では7～16単位、統合・試験段階では21～78単位のコストになることが示されました。 こうして固定化されるコストの多くは、日常的な設計判断のほんの一部から生じます。以下の4つの実践は、機械設計者と電気設計者が最も直接的に制御できる項目に対応するものです。 レイアウト開始前にコストを下げる4つのDFM実践 記事を読む
Requirements Portal における AI 支援要件インポーター Requirements Portal における AI 支援要件インポーター 1 min Blog エンジニアリングチーム エンジニアリングチーム エンジニアリングチーム Requirements Portal の AI 支援インポーターを使用して、PDF、文書、スプレッドシートを構造化された要件に変換する方法をご紹介します。仕様書、規格、複雑なプロジェクトを、トレーサビリティを維持したままインポートできます。 記事を読む
電子開発のための要件管理ツール エレクトロニクス開発に最適な要件管理ツールの選び方 1 min Blog システムエンジニア/アーキテクト 電気技術者 システムエンジニア/アーキテクト システムエンジニア/アーキテクト 電気技術者 電気技術者 スプレッドシート、メール、Word文書は、多くの電子開発チームにとって依然として要件管理ツールの主流です。それらは使い慣れており、柔軟で、使いやすいです。しかし、プロジェクトがより複雑になるにつれて、その場しのぎの要件管理はリスクとなります。 断片化した文書はメールやSlackのスレッドに閉じ込められ、チームメンバーやその他の関係者間での誤解を招きます。要件は進化しますが、下流のエンジニアが常に追いついているわけではありません。変更が発生したとき、その影響を追跡したり、完全に検証されたかどうかを把握する簡単な方法はありません。 その結果、プロジェクトの遅延、ボードの再設計、コンプライアンスの問題が発生します。 再作業の最大50%が要件の失敗に起因しており、失敗するプロジェクトの70%が要件の不備によって引き起こされます。解決策は単により良い文書ではなく、ハードウェア要件を扱うためのより良いシステムとツールです。 この記事では、電子開発のための要件管理ツールを評価する方法、避けるべき落とし穴、そして現代の協力的な電子設計チームにとって最も重要な機能について説明します。 なぜほとんどの要件管理プロセスが不十分なのか 表面上は、スプレッドシートやカンバンボードは要件管理に適した方法のように思えます。これらは情報を論理的で整理された方法で収集・表示するために設計されています。データはカテゴリ分けされ、フィルタリングされ、構造化されます。これらのツールは汎用性があり、異なるプロジェクトのニーズに合わせて形を変えることができるほど柔軟です。 しかし、非専門的なツールの一般的で高水準な性質が問題の一部です。これらは現代の電子機器開発の複雑さを扱うために設計されておらず、エンジニアやシステムアーキテクトが設計の反復とともに進化する数百または数千の要件を追跡するために必要な機能が欠けています。 最大の課題は可視性です。要件がタスク管理ツール、共有ドライブ、内部ウィキ、チャットスレッドに散らばっている場合、それらが最新の変更を反映しているか、またはテストケースが変更された要件をまだカバーしているかどうかを知る方法がありません。エンジニアは時間を無駄に二重チェックや相互参照に費やします。または、何も変わっていないと仮定することが、それよりも悪いです。 第二の問題はトレーサビリティです。専門の要件管理ツールがなければ、要件を設計要素や検証ステップにリンクすることは困難です。プロジェクトが終盤に近づくか監査の時になると、チームはなぜ、どこで決定が行われたのか、それがテストされたか、そしてそのテストが現在の設計の状態に対してまだ関連があるのかを再構築するために慌てます。 最終的に、これらの方法はスケールしません。チームが成長し、同時に複数のプロジェクトを手がけるにつれて、オーバーヘッドは指数関数的に増加します。スケールで切断された要件を管理する結果は、より多くの作業、より多くのやり直し、そしてより多くの無駄なお金です。 選んではいけないもの：要件管理ツールの一般的な落とし穴 要件管理用に市販されているすべてのツールがハードウェア開発に適しているわけではありません。多くは細かい点で失敗しますが、それでも電子設計のワークフローにとっては重大な影響を及ぼします。特に、チームがどんな構造化されたシステムでもアドホックな要件管理より良いと仮定する場合はなおさらです。 チームにとっての解決策を選ぶ際に避けるべき「機能」をいくつか探ってみましょう。 要件トレーサビリティ機能がない 一部のツールは、要件を静的なチェックリストのように扱います。それらは、要件を互いや回路図、テストケース、設計成果物にリンクする能力に欠けています。要件の収集には役立つかもしれませんが、それが終わると、本当に重要なコンテキストを欠いた構造化されたデータを持つことになります。 汎用タスクマネージャー ソフトウェア向けに構築されたプロジェクト管理プラットフォームは、自らをRMソリューションとして宣伝することがよくあります。しかし、要件をチケットとして割り当てることは、検証計画、ライフサイクル管理、またはECAD統合を効果的にサポートしません。要件データは収集され、レビューのために利用可能になりますが、プロセスの規律をツールの外で強制しなければなりません。 過剰設計されたレガシーRMプラットフォーム 一部のエンタープライズRMツールは、膨大な数の機能を備えていますが、現代の電子開発プロジェクトが求める使いやすさ、柔軟性、速度に欠けています。適切な手に渡れば、これらは優れたツールですが、専用の管理者、カスタムスクリプト、そしてチームを速く立ち上げるための数ヶ月のオンボーディングがしばしば必要です。これらは、迅速に動こうとするエンジニアリングチームには不向きです。 記事を読む