Mobile menu
Manufacturing Outputs and Compliance
ホーム Manufacturing Outputs and Compliance

Manufacturing Outputs and Compliance

Generate accurate manufacturing outputs while ensuring compliance with industry regulations, reducing production errors and time-to-market.

Altium's Manufacturing Solutions
Filter
見つかりました
Sort by
役割
ソフトウェア
コンテンツタイプ
適用
フィルターをクリア
不十分なデータ管理に起因する開発後の問題の評価 不十分なデータ管理に起因する開発後の問題の評価 1 min Blog どのような設計者やチーム、企業にとっても、設計をリリースまで漕ぎつけたときは安堵のため息をつける瞬間でしょう。しかしながら、この瞬間が常に喜びに満ちたものになるとは限りません。プロジェクトの完了には、次の2種類があります。a）ドキュメント化プロセスに何の不備もなく無事設計を完了しており、リリースの準備を開始できるケース。b）設計は問題なく完了しているが、データ管理プロセスに小さな（または大きな）誤りがあるため、修正と製造の後戻りが必要であり、製品リリースを遅延せざるを得ないケース。データ管理プロセスに何らかの不備がある場合、開発後はすべての局面を通じて後悔し続けることになりかねません。 開発後の懸念と後戻りの可能性 開発後の局面で懸念が持ち上がるのは当然のことであり、特にデータ管理についての不確定要素がある場合はなおさらです。ECADデータ資産の管理が十分でないと、ドキュメント化の方法が時代遅れになる傾向にあります。その場合、データ管理システムでエラーが非常に発生しやすくなり、ECADプロセスの多数の要素を手動で構成し直す結果になるおそれがあります。 ECADデータの正しい保存方法 ECADデータの保存場所は、その保存方法と同じくらい重要です。いまだに数多くの企業が、Dropboxなどの一般向けネットワークドライブを利用してECAD資産を保存しています。これは一見便利に思えるかもしれませんが、体系化された信頼できるデータ管理システムが設計方針に組み込まれていない限り、以下のような問題が生じるおそれがあります。 アクセスの制限 不十分なデータコントロール 異種の複雑なデータ ライフサイクルの非対応 プロジェクトを重視して体系化されたデータ管理システムがない場合、特定のファイルにアクセスできないだけでなく、データの配置ミスや紛失につながる可能性があります。 迷いのない製品リリース 開発後の不確定要素を評価するときは、仮説のわなに陥り、自分を見失いやすいものです。しかし、使用するリソース、データ管理戦略の正しい実施方法、データの保存場所をきちんと理解していれば、不安を確信へと変えることができます。現在のプロセスに疑いを抱いたり、損失の大きいエラーのために設計データの修正を余儀なくされたりした場合、貴重な時間が無駄になります。設計から製造までのプロセスを進める中で、このような問題を回避するには、正確なデータを体系化して、はじめから正しい方法で管理することです。 無償の ホワイトペーパー を今すぐダウンロードしてください。このホワイトペーパーでは、Altium Vaultを利用して、時間と予算を重視した賢明なデータ管理システム運用について説明しています。 記事を読む
設計ドキュメントの主要なPCB設計要素の捕捉 設計ドキュメントの主要なPCB設計要素の捕捉 1 min Blog ハードウェア製造業スタートアップ企業 / エレクトロニクスプロトタイパー ハードウェア製造業スタートアップ企業 / エレクトロニクスプロトタイパー ハードウェア製造業スタートアップ企業 / エレクトロニクスプロトタイパー 設計ドキュメント作成のうち最も重要でありながら、多くの場合に回避される要素の1つは、正式な設計ドキュメントです。設計を完了し、製造、実装、検証ドキュメントを生成しただけで、業務が完了したとみなしてしまうことは珍しくありません。システム仕様、設計の意図、設計プロセス、仕様の追跡可能性を正しく捕捉することは、時間を要し、骨の折れる作業ですが、極めて重要です。設計ドキュメントでは、システムの設計のあらゆる側面を捕捉し、関連するすべての設計情報へ簡単にアクセスできる必要があります。しかし、製造や実装の図面に含まれない設計の詳細をどのように捕捉すればいいのでしょうか? 設計の全ての側面を設計ドキュメントに表現する あらゆる設計において、設計ドキュメントの作成は計画段階で開始し、仕様から始める必要があります。設計ドキュメントの対象である設計が、より大きなシステムのサブシステムである場合、システム全体の仕様を提示してから、システム全体からそのサブシステムまで、システムがどのように分割されるかの仕様を記載する必要があります。設計プロセス全体を通して、設計ドキュメントは生きたドキュメントとなり、設計プロセスにおいて、それぞれの部分の回路が設計され、実装されていきます。 設計の仕様段階は、時間や予算の制約のために多くの場合見逃されたり、回避されたりする部分です。そこで、仕様を正しく開発するため、前もって時間とリソースを割り当てておくことが必要です。起動環境での作業に従事したことがあるなら、おそらくは仕様が不明瞭、またはまったく存在しない設計プロジェクトに直面したことがあり、この手法が危険であることを理解しているでしょう。仕様が存在しない、または固定されていない場合、その仕様に合わせて設計を行おうとすると、終わりのない開発のやり直しにはまり込むことになります。仕様の目的は、何を達成すべきかを明確にし、設計が完成したことを検証できるようにすることです。「もっと良いものを作れるはずだ」という考えから、プロジェクトが予算を超過し、スケジュールが遅延することは珍しくありません。このような結果が起きるのは、最初の時点で仕様を明確に決定しておかないことが主な原因です。 設計ドキュメントにおいて対象としているデバイスの仕様は、より大きなシステムのサブシステムであることも珍しくありません。システム全体の仕様が提示され、その後で設計対象のデバイスに適用される部分のシステムの仕様が、論理的で整った形式で示されます。 仕様には次の内容を含める必要があります（これで全部とは限りません）。 機能（サブシステムがどのような動作を目的としているか） 動作環境（温度、湿度など） 他のサブシステムとのインターフェイス パワーバジェット 利用可能な電源電圧 機械的な制約: サイズ、重量、形状 衝撃や振動に関する要件 熱（利用できる冷却、放射熱の放出制約など） EMIの放射、伝導、および感受性 信頼性 仕様ステージ以後にも、設計フェーズが完了したことを判定するため、関連する設計情報を捕捉する必要のある他の分野が存在します。正式な設計ドキュメントの作成には時間を要しますが、回路図、製造図、実装図の範囲を超えて、設計の全ての側面を捕捉するためには不可欠なことです。 正式な設計ドキュメントに、その他に何を含めるべきかについては、無料のホワイトペーパー 「設計ドキュメントによる設計の捕捉」 記事を読む
汎用コントローラーを2つのPCBに分割した方がよい理由 汎用コントローラーを2つのPCBに分割した方がよい理由 1 min Thought Leadership 私は常に、成功のためには他者の成功を真似し、失敗を避ける必要があると考えてきました。私が職務を始めた頃は、Raspberry Piのような単一基板のコンピューターは存在せず、Arduinoを産業アプリケーション向けに真剣に考える人はいませんでした。私が自分で設計した汎用コントローラーのメンテナンスを初めて行うことになったときの苦労を想像してみてください。それは、火災警報のコントローラーで、50本を超えるワイヤーが手作業でネジ止めされていました。私は、障害のある8ピンのEEPROM（Electrically Erasable Programmable Read-Only Memory）を交換する必要がありました。顧客は不満を持っており、私はこの作業を迅速に、間違いなく行うよう圧力をかけられていました。このときから、私は汎用コントローラーの設計を複数の物理モジュールに分割するようになりました。同様に今日、Raspberry Pi は産業用アプリケーションに使用されています。これはコストだけではなく、そのモジュール化設計のためでもあります。 汎用コントローラーとは 電子機器産業におけるコンポーネントと労働力のコストが増大し続けていることから、 デザインのフットプリントを最小限にする のは論理的です。しかし、汎用コントローラーの設計においては、長期的にこれが最良の選択肢ではないこともあります。 スマートフォンやテレビのような民生用電子機器とは異なり、汎用コントローラーは一般的な仕様で設計され、多くの場合に小規模で使用されます。ファームウェアが異なれば、同じコントローラーでも異なる機能を果たすようになります。例えば、同じコントローラーを支払い機のコントローラー、セキュリティ管理コントローラー、または単純なデータ監視ステーションとして使用できます。 一般的な汎用コントローラーは、次の部分で構成されます。 マイクロコントローラー（MCU） SRAM、 FRAM 、フラッシュ、EEPROMなどのメモリチップ 周辺機器インターフェイス（イーサネット、USB、 RS485 記事を読む
PCB回路製品: 修理できるように設計するべきか？ PCB回路製品: 修理できるように設計するべきか？ 1 min Thought Leadership 自分の手掛けたものを誰かに修理してもらわなければならないとき、私は技術者としての落ち度を感じてしまいます。それが電子機器であれ、たまにしか担当しない木工品であれ、まずは自分で何とかしてみるまでは助けを求めたくありません。ただし、配管となると話は別です。その場合は すぐさま 助けを呼ぶことになります。 自分が手掛けた製品は自分で修理したい―そんな衝動が働きますが、問題なのは多くの企業がそれを求めていないことです。ケースを空けるために専用のドライバーが必要になったために、ラベルを破いて正式に保証を無効にしたことは数え切れないほどです。しかも、バッテリー交換のためだけにです。ここで専門的なアドバイスを1つお届けしましょう。どうしてもバッテリーを交換したいのに、細長いネジ穴に対してドライバーが小さすぎるとします。この場合は、プラスドライバーと輪ゴムでどうにか対処できることがあります。まず、輪ゴムを細長いネジ穴の上に置きます。不安定な細長いネジ穴にドライバーがしっかりと、はまるまで押し込み、ネジを外します。 とはいえ、開けたケースが混乱と後悔の詰まったパンドラの箱に化けてしまったこともあります。LCDモニターは、VCRの焼け焦げたコンデンサーを交換するのとは大違いなのです。 自分が手掛けた機器の修理に対してどんな考えを持っていても、製品の設計を開始する前には、消費者による修理について必ず考慮すべきでしょう。消費者が自分で製品を修理できるようにするのか？消費者が自由に修理業者を選べるようにするのか？それとも、企業が提供するサービスや特別に訓練された技術者だけを利用できるようにするのか？では、いろいろな選択肢を比較しながら、関連する法的要件についても見ていきましょう。 社内での対応 多くの製造業者は、消費者が自分で製品を修理できないようにしたいと考えています。悩ましいところですが、多くの場合にこれにはもっともな理由があります。高電圧、傷つきやすい部品、特許で保護されたコンポーネントは、適切な予防措置がない状態で消費者に機器の分解を許可していない、という明確な理由です。 社内ですべての修理を行う場合は、送られてきた修理品や現地での修理に対応する十分に訓練されたスタッフが必要です。一方で、製品が「消耗品」であれば、修理するよりも新しいものに取り換えたほうが安くつく場合もあるでしょう。この場合は故障率を把握して、保証期間中に問題が発生したすべての製品を交換する体制を整備しなければなりません。 指定した技術者に修理を委託することもできるでしょう。 修理の選択肢を提供する 消費者が製品を修理できるものにしたほうが容易な場合もあります。コンポーネントの複雑さによっては、交換部品の販売が新しい収益源になることもあります。私が勤めていた会社では、元のハードウェアの交換と同じくらい独自のバッテリーの交換に対応していました。これは、プリンター用の新しいインクの購入に似ています。 いずれにしても説明書は作成する必要があるため、特別に訓練された修理業者を説明書に記載して提供することもできます。ここでは、適切なガイダンスと免責事項も含めておきます。たとえば、エンジン、回転翼、高電圧など、製品の中には安全に扱わないと危険なものがあるからです。警告ラベルが必要なコンポーネントが製品に含まれる場合は、修理ガイドに説明を明記しておきます。 オープンな修理については、諸経費を大幅に節約し、長期的にサービスを提供することができます。これは技術者にとってもありがたい話です。 法的要件 どの方法を採用するかにかかわらず、法的な要件についても考慮する必要があります。「消費者が合法的に所有している製品を自分で修理することは許可されるべき」という指針に基づいて、米国の複数の州で 「修理支持」の法律 の制定が進められてます。また、海外では修理に対応できないという議論もあります。これは特に、農業や自動車の業界にずっと依存してきた地域経済にとっての強力な動機でしょう。 一部の大手企業は、この法案に積極的に反対しています。多くの場合、これは特許を取得できる設計に関して懸念があるからです。また、顧客にメンテナンスサービスを提供するための独占請負契約からの収益を守りたいと考えている企業も数多く存在します。 中小企業では、請負契約や売上の競争が激しくなるでしょう。この法案の支持者は、独占的なサービスでなく顧客サービスによって成り立つ市場を期待しています。修理する権利を持つ消費者は修理したハードウェアを売買しやすくなるものの、それによって企業の全体的な売上が減少する可能性があります。 記事を読む
最も完璧なドキュメントパッケージをPCBの製造部門に送る方法 最も完璧なドキュメントパッケージをPCBの製造部門に送る方法 1 min Blog 開発ステージの完了は常に喜ばしいことです。ちょうど今、PCBプロジェクトの最後のハードルを乗り越えたところだと考えましょう。それは新しいコンポーネントの数量確保、環境テストの最終化、またはEMC（電磁両立性）技術者からの承認かもしれません。これで基板は「リリース済み」状態になり、全ての承認が署名され、あとは製造に渡すだけです。設計仕様を作業可能なファイルに変換し、翻訳して、PCB製造業者に渡す手順は単純明快であるべきですが、実際には、そうではありません。 ドキュメントの一部が欠けていただけでも、設計者の仕様と、ドキュメントに記載されているものとを結びつけるラインは簡単に不明瞭となり、製造プロセスは簡単に停止してしまいます。「悪魔は細部に宿る」という諺は、PCBの製造や実装のドキュメントについて、まさに的確に当てはまります。複数の利害関係者が関与するプロジェクトの期間に起きたことを伝達する真実の単一の情報源として、より多くより詳細に記載するほど良い結果が得られます。設計後のプロセスを行うため使用できる全てのツールと、必要な製造ファイルの出力を使用することで、製造業者が当て推量を行い、見解の相違のため高い見積もりを要求することや、製造プロセスが遅延することや、さらに悪い結果として仕様を満たさないPCBを構築してしまうことを避ける必要があります。設計の意図をデジタルの世界から物理的な製品に変換するには、製造業者の観点から見て、完全なドキュメントパッケージはどのようなものかということを、的確に理解する必要があります。 製造ファイルの基礎 製造業者の観点から見ると、設計ファイルで参照されるドキュメントが1つでも欠けていれば、それは大きなエラーです。不完全な製造ドキュメントはほとんどの場合、問題の明確化と軽減に浪費される時間から、プロジェクトの遅延を招きます。そこで、ここに示すような 出力ファイルの分類 をまず覚えてください。 製造ドキュメントのパッケージが完全なだけでなく、PCB業界で一般的に受け入れられているフォーマットでパッケージを製造業者に送る必要があることにも留意してください。 PCB設計について最も一般的に受け入れられているファイル形式は、ガーバー（標準のRS-274-Dまたは拡張のRS-274X）、ODB++、およびExcellonです。さいわい、ほとんどのCADシステムは、これらのフォーマットのいずれかで設計データを生成またはエクスポートできます。そして、実際に製造業者へデータを送る前に、どのような製造ファイルを、どのフォーマットで必要としているのかを、製造業者との間で正確に確認しておくべきです。しかし、例外はありますが、自社内のCADフォーマットで設計を製造業者に送ることは常に避けるべきです。この単一のファイルフォーマットは多くの場合、製造業者では読み取り不能で、基板の製造に使用できません。 含めるべきもの それでは、最低限何を含めればいいでしょうか? これは製造業者によって異なりますが、製造業者が顧客と十分に情報を共有していることを確認するため、多くの場合に最低限必要とされるドキュメントは次のものです。 次のデータを含むPCBデータ ガーバーデータ ドリルデータ ネットリストデータ 次のデータを含むPCB製造指示 長穴および穴サイズ 基板の外形 完成した銅箔の重量 完成したPCBの厚さ 記事を読む
デザインリリースの管理と意図の伝達 デザインリリースの管理と意図の伝達 1 min Blog かつてないほど、現代の技術は、スマートフォンからソーシャルメディア、衛星通信さらにはその先まで、地球規模の通信ネットワークを容易にしています。私たちは常々、私たちを分断し意思疎通を制限する障壁を取り除くことを求められています。残念ながら多くの企業が、設計エンジニアリングにおいて、彼らの意図とデザインリリース管理の目的をはっきりと伝達することに現在もなお苦労しています。適切な管理システムを備えていない場合、設計ライフサイクルにおいて全ての利害関係者がそれぞれの役割を確実に果たすことは困難であり、製品リリースを遅らせる無数の失敗につながる恐れがあります。 デザインリリースプロセスが管理されていない場合の問題点 ご存知のように、製品の設計とリリースは分野横断的な命令系統に関わっています。デザインリリースの前に、ECAD側は、設計の増分的な変化を取り込むために何度も調整作業を行います。この段階では、ECADデータは常に変化しています。そのため、関係者への情報伝達の流れが滞る恐れがあります。これらの変化を効率的に情報伝達できない場合、デザインリリースプロセスに重大な結果をもたらすことがあります。その具体例を以下に示します。 ECADバージョンとリリースデータが適切に管理されていない 間違ったバージョンの設計を製造部門に送ってしまうリスクが高い 陳腐化した部品を使用してしまうリスクが高い 設計リリースの準備ができてから実際にリリースされるまでに時間の無駄が発生する 手書きの承認署名を得るのに時間がかかる 標準化された設計プロセスの実施が困難である データ管理システムが自動化されていないと予定される製品リリースに多くの脅威を及ぼす恐れがある一方、適切なECADリリース管理システムを使うと、これらのリスクを早期に検出できます。 ECADリリース管理におけるギャップの解消 プロジェクト管理チーム内の透明性を高めるため、一部の企業は製品ライフサイクル管理（PLM）システムを構築する方向に向かっています。これにより人手によるプロセスの限界を打ち破り、設計ファイルの高度な制御が可能になります（しかし、PLMが最も有利な方法であるということではありません）。この投資による成果は、多くの場合以下のような形で現れます。 エンジニアの時間の無駄が少なくなった 製品のコストを削減できた 製品の品質が向上した 開発サイクルを短縮できた リリース管理プロセスの掌握 多くのエレクトロニクス企業がさまざまな方法を使ってこれらの課題に立ち向かおうとしていますが、その目的は同じ、つまりリリース管理プロセスを完全に同期させることです。どの設計段階にあっても、統合ECAD管理システムの導入を検討するのに遅すぎることはありません。統合ECAD管理システムの導入は、設計者、企業、全ての利害関係者に、製品が品質要件を満たすことが確認できるという安心感を提供します。 無償のホワイトペーパーを今すぐダウンロードしてください。このホワイトペーパーでは、Altium Vaultが 記事を読む
設計要件に対して最適なIoTプロトコルの選択 設計要件に対して最適なIoTプロトコルの選択 1 min Thought Leadership IoT製品設計は、新しいノートパソコンの購入と似ている部分があります。速度、コスト、機能、相互運用性など多くの要素を検討する必要があります。最終的には、これらの要素のうち1つまたは2つを特に重視し、他の要素を可能な限り最適化することになります。私の場合、何年にもわたってLinuxコンピューターだけを使用してきましたが、Microsoftファイルの共有が必要になったとき、相互運用性の制約は厳しいものでした。最終的に私は妥協し、コンピューターをWindowsとのデュアルブートに設定しました。 オープンソースでも独自のものでも、ほとんどのシステムにおいて相互運用性は重要です IoT製品の相互運用性についての質問は、使用する通信プロトコルに依存します。これは、ほとんどの製品は別のプロトコルを使用してシステムと通信できないためです。選択するプロトコルは、ハードウェアにも影響を及ぼします。例えば、伝送距離によってシステムで利用可能な IoTモジュール、電力要件、 ネットワーク構成が決まります。 プロトコルの選択方針 選択可能なプロトコルは膨大な数にのぼります。新しいバージョンが 毎年誕生し、グループは既存の オプションの統合を試みています。自分の製品に最適なプロトコルは、どのように決定すればいいのでしょうか? 国際的な標準を策定しようとすることは、それ自体が混乱を、絵文字についてさえも引き起こします。 検討の必要があるすべてのオプションにストレスを与える前に、いくつかの助言を行いたいと思います。これは正直なところ、私自身が最初のIoT設計を行う前に 読んでいればよかったと思うものです。「結局のところ、 それを使わないこと自体が間違いであると言えるほど浸透している、または重要である標準は存在しません」（テキストの強調は私が加えたものです）。 1. 優先度の特定 IoT Centralが開発者の動向について行った 2017年の調査によれば、IoTについて最も重要な懸念はセキュリティと相互運用性です。セキュリティは、 物理的なPCBから ユーザーデータの保存まで、製品設計のあらゆるレベルで対処が必要です。相互運用性はもう少しだけ簡単です。適切なプロトコルを選択することで、自分の製品が属するIoTエコシステムを最大化することが可能です。 記事を読む