Skip to main content
Mobile menu
Discover
Develop
Agile
リソース&サポート
リソース&サポート
ラーニングハブ
サポートセンター
マニュアル
Webセミナー
Altium Community
フォーラム
バグの報告
アイディア
Search Open
Search
Search Close
サインイン
組込みソフトウェア
Main Japanese menu
ホーム
PCB設計
PCB設計コラボレーション
コンポーネント管理
設計データ管理
製造出力
ECAD-MCAD共同設計
高密度配線(HDI)設計
高速設計
マルチボード設計
PCBレイアウト
PCB配線
PCBサプライチェーン
パワーインテグリティ
RF設計(高周波回路)
リジッドフレキシブル基板設計
回路設計
シグナルインテグリティ
シミュレーション/解析
ソフトウェアプログラム
Altium 365
Altium Designer
PDN Analyzer
リソース
エンジニアリングニュース
ガイドブック
ニュースレター
ポッドキャスト
Webセミナー
ホワイトペーパー
ホーム
組込みソフトウェア
組込みソフトウェア
PCB設計用の組み込みソフトウェアの詳細について、リソースライブラリをご覧ください。
Overview
All Content
Filter
見つかりました
Sort by
最新
人気順
タイトル(昇順)
タイトル(降順)
役割
電気技術者
ITマネージャー
PCB設計者
ソフトウェアエンジニア
ソフトウェア
Altium Designer
Altium 365
Octopart
コンテンツタイプ
ホワイトペーパー
ハードウェア・イン・ザ・ループテスト:イントロダクション
1 min
Thought Leadership
「ハードウェア・イン・ザ・ループ」テストを検索すると、複雑なリアルタイムシステムの例が頻繁に見つかります。 例えば、このNational Instrumentsの記事は、ハードウェア・イン・ザ・ループ(HIL)が何であるか、そして自動車内の電子制御ユニットのテストの例を提供している上で、素晴らしい説明と背景を提供しています。この記事では、HILテストコンセプトのより小さく、より取り組みやすいバージョンに焦点を当てます。 ハードウェア・イン・ザ・ループテストとは何か? この記事の目的のために、我々はハードウェア・イン・ザ・ループテストを従来提示される方法(例えば、自動車アプリケーション内で)とは少し異なる方法で定義します。製品をテストする際の複雑さの異なる三つのレイヤーを観察しましょう。 テストフォーマット1:基本的な手動テスト このテスト形式では、エンジニアがデバイスを手動でテストします。これには、デジタルマルチメーターで基板上のテストポイントを探る、オシロスコープで波形を観察する、またはコンピューター画面上でテレメトリー読み取りを手動で解析することが含まれます。エンジニアは、手動の設計検証テストを通じて製品をテストします。 テストフォーマット2:自動テスト このテストセットアップは、通常エンジニアによって行われる同じ測定と検証を実行しますが、コンピュータによって自動化された方法で実行されます。ホストコンピュータは直接計測器(例:マルチメーター、オシロスコープなど)に命令を出し、デバイスからのテレメトリを解析し、その後、エンジニアによって設定された基準に基づいてテストセットを検証します。 テストフォーマット3:ハードウェア・イン・ザ・ループテスト ハードウェア・イン・ザ・ループテストは、実世界のアプリケーションをシミュレートする追加の刺激を加えることで、自動テストを新たなレベルに引き上げます。例えば、テスト対象のデバイス(DUT)には、刺激が必要な一連のセンサーがあるかもしれません。テスト機器は、それらのセンサーの他端をシミュレートして、DUTのセンサー側を刺激します。別の例としては、DUT上のRS-422レシーバーにRS-422トラフィックを駆動することが挙げられます。私たちがDUTに新しい刺激を駆動し、ホストコンピュータからテレメトリを読み取り、必要に応じてテストを適切に調整できる(例:初期テストを通過した後に、より速く、より多くのRS-422トラフィックを駆動する)という考えです。 ハードウェア・イン・ザ・ループを採用する利点 アプリケーションに基づいて、なぜハードウェア・イン・ザ・ループ(HIL)テストを自動テスト(そしてもちろん手動テスト)よりも採用するかが明確になる場合があります。複雑なシステム、または(システムのシステム)を統合しようとしている場合、多くの外部刺激が必要であれば、基本的な自動チェックアウトテストでは不十分です。基本的なバッテリーチャージャーを考えてみましょう。電源、負荷、バッテリーをシミュレートしてコントローラ回路をテストすることはできますが(物理的にもソフトウェアを通じても)、実際の電源、バッテリー、負荷を使用して設計をテストする方が現実的です。さらに、このプロセスを自動化できれば、エンジニアはテストよりも開発に時間を費やすことができます。 コスト分析:それは価値がありますか? ハードウェア・イン・ザ・ループテストを採用するかどうかを決定する際には、次の要因を考慮する必要があります: テスト時間:デバイスのテストにどれくらいの時間を費やす予定ですか?基本的なチェックアウトを行って終わりですか、それとも数ヶ月のテストが必要ですか? テストの再発生:同じテストをどれくらいの頻度で実行しますか?このテストセットアップ(つまり、機器と自動化スクリプト)は将来の設計に使用できますか? テスト機器:自動テストと手動テストに必要な機器を揃えるコストはどのくらいかかりますか? これらおよびその他の要因を考慮したら、手動テストを続けるか、自動/ハードウェア・イン・ザ・ループテストに投資するかの決定を始めることができます。 始め方
記事を読む
ワークフローを平滑化する:「フラット」スタイルのプロジェクト管理ガイド
1 min
Blog
フラットな組織が人気を博すにつれて、それに伴う方法やプロセスも同様に普及しています。このブログでは、フラットな組織構造自体ではなく、プロジェクト管理の領域内でフラットな組織がどのように機能するかについて議論します。フラットな組織から学んだプロジェクト管理の原則は、最もフラットな会社から最も階層的な構造を持つ組織まで採用することができます。 「フラット」であることは流行っていますが、なぜそれを行うべきなのでしょうか? 「なぜフラットなプロジェクト管理に興味を持つべきか?」という質問をしているかもしれません。プロジェクトマネージャーにとって、答えはシンプルです:委任の必要が少なく、状況の確認を求めることが少なく、監視も少なくなります。これは、あなたが好きなことにもっと時間を割くことができるということを意味します... それが仕事の管理を楽しんでいる場合は(その場合はここで読むのをやめるべきです)。管理される側にとっても、明らかです:なぜ常に状況を追及され、仕事の正しいやり方を「助言」される必要があるのでしょうか?再び、それが好きなら、これはあなたにとって正しいスタイルではないかもしれません。ここでの考え方は、マネージャーが少ない管理を必要とし、他のすべての人が自分の仕事を望むように自由に、そして自律的に行うことができるということです。 前提条件 プロセス自体を始める前に、これを実際に機能させるための3つの主要な前提条件があります:信頼、透明性、そしてコミュニケーション。 ここ 図1. 信頼、透明性、コミュニケーション 信頼:お互いを信頼することは、フラットなプロジェクト構造を成功させるための鍵です 透明性:全員が自分が何をしているのかを完全にオープンにする必要があります。これは、以下のようないくつかの媒体を通じて彼らの仕事を伝えることで行うことができます: コードのコミット Wikiページ 課題追跡システム エスプレッソマシン(つまり、新しいウォータークーラー) コミュニケーション:全員が互いにコミュニケーションを取る能力を持ち、そうすることが奨励されるべきです。 信頼があるところには透明性があります。透明性があるところでは、人々は安全だと感じ始めます。人々が安全だと感じ、自分の仕事についてオープンであることが奨励されると、コミュニケーションは自然に起こります。 実装 前提条件をカバーしたので、フラットプロジェクト管理の実装について話し合うことができます。 プロジェクトリーダー:「でも、フラットな構造では誰もボスではないと思っていましたが?」確かに「指揮と管理」に従事する必要がある人はいませんが、ファシリテーターがいることは重要です。プロジェクトリーダーを、全員が調和して同じリズムで演奏していることを確認する指揮者だと考えてください。
記事を読む
組み込みシステムの実装とテストの実施
1 min
Blog
これらのシステム内の組み込みシステムとPCBは、展開前に徹底的にテストされる必要があります。
記事を読む
必須のPCB設計のヒント:PCB設計にウォッチドッグタイマーを実装する方法
1 min
Thought Leadership
在宅勤務には仕事のメリットがいくつかあります。自分で食事を作ることができ、昼休みに洗濯をすることができ、好きなだけお茶を飲むことができます。私はお茶のために水を沸かすためにストーブトップのケトルを使用しているので、執筆に没頭しているときは、高い音のホイッスルでお湯が沸いたことを知らせてくれるのを頼りにしています。 時々、不注意で蓋をきちんと閉めないことがあります。その結果、ケトルは静かなままで、中の液体の水が急速にガスに変わっていても音を立てません。このシナリオでの私の不注意な行動は、お茶を少なく飲むことを意味するだけですが、組み込みシステムでは、ウォッチドッグタイマー(WDT)の操作方法を知らない場合、その結果ははるかに重大です。タイマーの操作に失敗すると、停止したマイクロコントローラーは停止したままとなり、組み込みシステムがダウンしたままになります。ウォッチドッグタイマーの仕組み、ウォッチドッグタイマー回路の実装方法、そして最初の試みで正しく機能させる方法を見てみましょう。そうすることで、このシナリオを避けることができます。 組み込みシステムがWDTを持っていても回復できなかった理由 ウォッチドッグタイマーは、ハードウェアまたはソフトウェアのウォッチドッグ回路がクラッシュした場合にマイクロコントローラーを再起動するための、電子機器におけるシンプルなフェイルセーフ機能です。STM32ウォッチドッグタイマーは、別の集積回路(IC)として、またはマイクロコントローラー自体に組み込まれた機能として利用可能です。組み込みシステム設計においてWDTを使用しないことは、しばしば許されない過ちです。 ウォッチドッグタイマーの動作方法はシンプルです。設定されたウォッチドッグタイムアウト間隔でカウントダウンするようにプログラムされます。通常の操作では、マイクロコントローラーは定期的にタイマーのカウントダウンタイマーをリフレッシュして、それが期限切れになるのを防ぎます。マイクロコントローラーが応答しない場合、ウォッチドッグタイマーをリフレッシュしません。その結果、ウォッチドッグタイマーが期限切れになると、マイクロコントローラーをリセットするためのパルスまたは信号をトリガーします。このシンプルな機能は、マイクロコントローラーがクラッシュする可能性がある設計ミスや環境要因を補償します。 しかし、WDTが失敗した場合、組み込みシステムが誤った状態から回復する可能性は低いです。これが、ウォッチドッグタイマーがマイクロコントローラーをリセットできない原因を特定することが重要である理由です。最も明白な答えは、ウォッチドッグタイマーチップが故障していることです。しかし、複数のユニットで組み込みシステムが回復できないと繰り返し発生する場合、設計に何か問題がある可能性があります。 実際に、私が設計し展開してきた数百のマイクロコントローラーベースのデバイスの中で、STM32ウォッチドッグタイマーが故障したという事例には一度も遭遇したことがありません。根本的な原因は、しばしば単純に人為的なミスです。 WDTが正常に動作しない可能性がある理由 内蔵WDTを使用する組み込みシステムでは、実行中のコードがウォッチドッグタイマーを無効にする可能性があります。これは、設定ビットが意図せずに上書きされた場合です。 外部ウォッチドッグタイマーチップは、全く異なる問題に直面します。この場合、ファームウェアエンジニアがプログラムを開発およびデバッグしているときに、外部ウォッチドッグタイマーからのリセット信号を切断できるジャンパーピンが一般的に存在します。しばしばこれらのジャンパーピンは、現場に展開する前に手動で接続する必要があります。接続されていない場合、WDTのリセット信号は切断されたままとなり、マイクロコントローラーをリセットできません。 ウォッチドッグタイマーが機能しない一般的な理由の一つは、コーディングエラーによるものです。WDTタイマーをリフレッシュする関数がプログラムの間違った部分に配置されている場合、それらは本来機能すべき時に動作しません。 リアルタイムオペレーティングシステム(RTOS)では、異なる優先順位を持つ複数のタスクがあると、マイクロコントローラのファームウェアが複雑になります。優先度の高いウォッチドッグ回路タスクは、優先度の低いタスクが異常な無限ループにある場合でも実行を続けることがあります。ウォッチドッグタイマー回路のリフレッシュが最優先タスクである場合、マイクロコントローラは正しく機能していないときにリフレッシュされません。 WDTが信頼性を持って機能することを確実にする方法 WDTがその役割を果たすことを確実にするには、ファームウェア開発者、システムインストーラー、およびハードウェアウォッチドッグ設計者が関与します。ファームウェア開発者は、内部WDTをオフにするコードオーバーランを避けるために プログラミングのベストプラクティスを適用するべきです。ファームウェア開発者は、マイクロコントローラのメモリアーキテクチャと、コード内でメモリポインターと割り当てを正しく使用する方法をよく理解していなければなりません。 その他にも、プログラムの構造は、ウォッチドッグタイマーがプログラムの適切な位置でリフレッシュされるように設計されるべきです。これは、プログラムのどこかで無限ループが発生した場合にプログラムがウォッチドッグリセットをトリガーすることを意味します。また、WDTの機能を現場でチェックするテストユーティリティを開発することもできます。これにより、外部ウォッチドッグタイマーとマイクロコントローラーの間の接続されていないジャンパーピンを見逃すリスクも排除されます。 高品質な製造可能な回路基板を構築するために必要なすべてを含む使いやすいPCBレイアウトツールにアクセスする必要がある場合は、 CircuitMakerをご覧ください。使いやすいPCB設計ソフトウェアに加えて、すべてのCircuitMakerユーザーは Altium 365プラットフォーム上の個人ワークスペースにアクセスできます。設計データをクラウドにアップロードして保存し、安全なプラットフォームでウェブブラウザを介してプロジェクトを簡単に閲覧できます。
記事を読む
製品のサービスが行いやすくなるよう設計を最適化する方法
1 min
Thought Leadership
十分に準備を整えたつもりで何かに立ち向かったところ、何をすべきか全くわからないという感情を味わったという経験はあるでしょうか? 残念なことに、私は思い出したくないほど数多くこのような経験をしています。特に、サービスを行いやすくなるように製品を設計する、または修理を考えて設計を開始したときに、頻繁にこのような経験をしました。 サービスを行いやすくなるように製品を設計すべきか どうかを決定する前に、考慮すべき多くの要因が存在し、その現実性について十分な時間をかけて考慮する必要があります。最終的に、修理を考えて設計を行うことを決定した場合、製品のサービスとトラブルシューティングが簡単になるような機能を含める必要があります。私は初期の設計ミスから、サービスを行いやすくなるよう設計を最適化する方法を学びました。いくつかの役に立つヒントをここで紹介しましょう。 1. 視覚的なインジケーターを追加する オンサイトで電子機器のサービスを行うのは、サポートチームの手に余ることがあります。特に、誤動作が重要な動作の遅延を引き起こしている場合にはその傾向が強くなります。いくつかの視覚的なインジケーター、例えばLEDやLCDを的確に配置すると、サポートチームが問題を迅速に特定するのに役立ちます。LEDを使用して、基板に電力が供給されていること、マイクロコントローラが動作していること、基板がデータを正しく送受信していることなどを表示できます。 2. PCBにラベル付けする 技術サポートチームに最新の回路図を渡しておいたとしても、基板上のコンポーネントに正しくラベル付けしておかなければ、正しい部品を探すために多くの時間を費やすことになります。コンポーネントへモジュールに応じて割り当てを行うシステムを使用し、正しいコンポーネントのとなりに シルクスクリーンラベル が配置されていることを確認します。また、基板接続へのワイヤのデジグネータの横に、意味のあるラベルを追加します。「PC」などのラベルを使用すると、そのコネクタがPCに接続されていることを技術者が容易に認識できます。さらに、受信ワイヤ接続で極性が重要な場合、「+」や「-」などの極性サインを追加することも適切です。 3. エラーのログ出力機能の実装 複雑な組み込みシステムを設計するとき、エラーのログ出力を無視することはできません。ほとんどの場合、ラボでのテストで見逃された 問題やバグ は、現場で追跡するのが困難です。これらの問題は多くの場合、変数の組み合わせによってトリガされ、簡単に再現できません。さらに悪いことに、サポートチームが問題に取り組もうとしたときには、システムは既にリセットされている可能性があります。最低でも、EEPROM(Electrically Erasable Programmable Read-Only
記事を読む
IoTストレージ技術: 超低消費電力CBRAM
1 min
Thought Leadership
ずっと昔、あのフロッピーディスクを使っていたことを覚えていますか? 私のコンピューターにフロッピーディスクドライブが2つ付いていたのを覚えています。一方のドライブにプログラムの入ったディスクを入れ、もう一方にデータ用のディスクを入れていました。そのうち、ハードディスクという驚くべき発明品が登場し、保管容量は爆発的に増えました。メモリ容量は、まだ増加を続け、今ではサイズは、それほど有用な要素でなくなりつつあります。モノのインターネット(IoT)の場合、エネルギー消費が次の重要項目です。スマート家電からスマートシティまで、あらゆるものが構想されており、これらが機能するには、非常に消費電力が低いメモリが必要となります。そこで、超低消費電力CBRAM(導電性ブリッジング ランダムアクセスメモリ)の出番です。Adestoは、他のストレージ技術の1/100の電力で動作できるかもしれない、この技術を推進している主要な企業です。 もはやこれらは必要ありません。 低消費電力の要件 先ほど、ストレージのサイズは問題ではない言いましたが、それは嘘です。デバイスが小型化するとともに、小さなバッテリーで動作できる、より小型のメモリが必要となります。特にウェアラブル機器は、フォームファクターの小型化と効率的なエネルギー利用について、この傾向を促進しています。機械の小型化に加えて、広域IoTセンサーネットワークも、低消費電力ソリューションを必要としています。 メモリが増加しただけでなく、計算能力も向上しました。今日のスマートフォンは、NASAが月旅行に使用したコンピューターより 何百万倍も強力 であると言われています。ウェアラブル電子機器は、まだまだそのレベルに達していませんが、その方向に向かっています。より強力になりつつあるだけでなく、スマートウォッチは、 センサー機能の統合 を始めつつあり、高度なユーザーインターフェイス(UI)とサポートアプリケーションを既に備えています。プロセッサー、センサー、アプリは、 動作するためにエネルギー効率の高いメモリを必要とします 。そうでなければ、1日に何度もウォッチを外して充電することが必要になり、誰もそれは望みません。 低消費電力を本当に必要とするもう1つの領域は、低消費電力高域ネットワーク(LPWAN)で使用されるデバイスです。人は長い間、「スマートシティ」を構想してきました。そこでは、 自動車が自分で駐車スペースに止まり 、 インフラが効率的に監視、保守され 、 公共の利益を求めてデータマイニングが行われます 。これらのシステム全てに共通していることは、何でしょうか
記事を読む
PLCと組み込みシステムとの比較: ユニット単価が高くてもPLCを選択すべき場合
1 min
Thought Leadership
評判の高い、豪華なレストランで夕食を取ったことがありますか? そのときは、かなりの金額を支払ったことでしょう。しかし、素晴らしい夕食を希望し、それを楽しめたなら、その金額は十分に価値のあるものだったはずです。これに対して、平均的な地元のレストランで、サンドイッチが予想額より20ドル高かったら、馬鹿げた話だと思うのが当然です。このような場合は、そのお金で料理教室に通い、自分で料理を作った方がずっとマシというものです。 私は電子機器設計者として、プログラマブル ロジックコントローラー(PLC)やローカライズされた組み込みシステムで同様の経験があります。PLCを、ローカライズされた組み込みシステムに置き換えることで、コストを大幅に削減できます。しかし、豪華な夕食が支払い金額に見合う価値があるように、より高価な選択肢であるPLCの方が適切な選択となる状況もあります。 PLCとその応用 プログラマブル ロジックコントローラー は産業用に特化したコンピューターです。入力信号(デジタルまたはアナログ)を監視し、論理演算を実行し、特定の出力信号を出力するようカスタムプログラムされています。PLCは堅牢であることが知られており、産業用の極端な環境や、障害がほとんど許されないようなアプリケーションで一般に使用されます。 PLCが一般的なのは、モジュール構造のためです。これによって、プラグアンドプレイの手法で簡単に組み入れできます。最も基本的な構造は、中央処理装置(CPU)、電源、入力/出力(I/O)モジュールで構成されます。PLCのプログラミングは、マイクロコントローラーのコーディングよりも簡単です。これは、製造業者から供給されるラダー図、機能ブロック図、およびソフトウェアについての構造化テキストを中心としてプログラミングが行われるためです。 PLCは産業用アプリケーションにおいて珍しいものではありません。生産ライン、交通信号、エスカレーター、HAVAシステムなどに一般的に使用されています。これらのPLCは基本的なデータ操作機能があり、 Modbus や DeviceNet など各種の通信プロトコルを対応できます。これらの機能から、自動制御システムに好んで使用されています。 PLCの設定はほとんどプラグアンププレイで行われます。 ローカライズされた組み込みシステムがPLCに置き換わることがある理由 一般に、組み込みシステムとは、ハードウェアとソフトウェアが連携動作し、アプリケーション固有の機能を提供するものと定義されます。電子機器設計者の視点からは、これはマイクロコントローラー(MCU)、メモリチップ、 電源管理回路 、通信モジュール、入力/出力機能で構成されます。 これはPLCと似ていますが、両者の間には明確な相違点があります。
記事を読む
Pagination
First page
« First
Previous page
‹‹
ページ
1
ページ
2
ページ
3
現在のページ
4
ページ
5
Next page
Next ›