筆者について

Ari Mahpour

Ariは、設計、デバイスパッケージ、テスト、および電気、機械、およびソフトウェアシステムの統合において幅広い経験を持つエンジニアです。彼は、設計/デザイン、検証、テストのエンジニアをまとめて団結したグループとして機能させることに情熱を注いでいます。

最新の記事

低コストソリューションで自動化されたハードウェア・イン・ザ・ループテスト

ハードウェア・イン・ザ・ループテスト自動化のための低コストソリューション 1 min Blog プロジェクトの概要：Pytestフレームワークを使用した自動化されたハードウェア・イン・ザ・ループテストのための低コストソリューションの実演

同じプロジェクト内の複数のPCBのデザイン作業

同じプロジェクト内の複数のPCBのデザイン作業 1 min Blog PCB設計者

PCB設計者

プロジェクトリーダー（マネージャー）

PCB設計者

プロジェクトリーダー（マネージャー）

プロジェクトリーダー（マネージャー）弊社の PCB設計の大部分は、 Altium Designerプロジェクト(すなわち.PrjPcbファイル)に従って単一のPCB に配置されます。時々、さまざまなスタッフィングオプションを持つバリアントを使用してデザインします。さまざまなスタッフィングオプションを備えた複数のPCBを必要とする単一のプロジェクトを扱うことはめったにありませんが、そのようなプロジェクトが発生すると、私たちの多くは行き詰まる傾向があります。設計者がプロジェクトをフォーク(すなわちコピーアンドペースト)し、回路図および(または)PCBにわずかなバリエーションを追加するのを何度も見てきました。一般的に、この技法はデザインに戻って更新する必要がある時を除き容認されます。両方のプロジェクトで正確な変更をどのように処理していますか？これらの変更が同一であることをどのように保証しますか？これは何回発生しますか(改定A 、B 、Cなど)？この記事では、単一のプロジェクト内で複数のPCBデザインを管理し、信頼できる唯一の情報源(SSOT：Single Source of Truth)を確保する方法について説明します。私の最後の記事「パンデミック時代の試作活動：リビングルームから電子機器を構築する」を使って実例の精査も行います。プロジェクトファイルのセットアップここでの目的は、回路図内でSSOTを維持しながら、それでもPCB自体のバリアントを配線できるようにすることです。この例では、単一の回路図を作成しましたが、2つのPCBを備えています。また、上部にバリアントも表示されます。キルンコントローラー用に2つのバリアントを作成しました。1つは Raspberry Pi(標準サイズ)用、もう1つはRaspberry Pi Zero用です。標準的なサイズは基本的にZeroの大きいバージョンなので、私はRaspberry

ハードウェア・イン・ザ・ループ・プロジェクトの設定

ハードウェア・イン・ザ・ループ・プロジェクトの設定 1 min Altium Designer Projects この記事では、Altium Designerで設計されたボードの例題プロジェクトを紹介し、そのファームウェアに対してハードウェア・イン・ザ・ループテストを使用したDevOpsフローを実行する方法について説明します。

Concord Pro と Git サーバー間の自動ミラーリング

Concord Pro と Git サーバー間の自動ミラーリング 1 min Blog Altium Concord Pro サーバーの Git サーバーミラーを作成できます。これにより、オンプレミスの Concord Pro インスタンスからプロジェクトのバックアップを簡単に作成する方法が提供されます。

ハードウェア・イン・ザ・ループテスト：イントロダクション

ハードウェア・イン・ザ・ループテスト：イントロダクション 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ページ課題追跡システムエスプレッソマシン（つまり、新しいウォータークーラー）コミュニケーション：全員が互いにコミュニケーションを取る能力を持ち、そうすることが奨励されるべきです。信頼があるところには透明性があります。透明性があるところでは、人々は安全だと感じ始めます。人々が安全だと感じ、自分の仕事についてオープンであることが奨励されると、コミュニケーションは自然に起こります。実装前提条件をカバーしたので、フラットプロジェクト管理の実装について話し合うことができます。プロジェクトリーダー：「でも、フラットな構造では誰もボスではないと思っていましたが？」確かに「指揮と管理」に従事する必要がある人はいませんが、ファシリテーターがいることは重要です。プロジェクトリーダーを、全員が調和して同じリズムで演奏していることを確認する指揮者だと考えてください。