これまでの章では、構成ソフトウェアと保守ソフトウェアについて何度も触れてきましたが、それらがプラットフォームアーキテクチャ全体の不可欠な部分であることにも気づくかもしれません。しかし、現実はしばしば無力であり、私のキャリアでは、これら2つのソフトウェアモジュールも不運なものです。
国内のソフトウェアの雰囲気は良くなく、企業はハードウェア機器にお金を使う気はありますが、純粋なソフトウェアプロジェクトにお金を使う気はありません。この一般的な環境では、企業は組み込み機器の分野により多くのリソースを投入せざるを得ませんが、周辺機器ソフトウェアについては、可能であればそれを保存してください。
たとえば、私が初期のR＆Dの経験があり、新製品を作りたい場合、マーケティング部門が承認する限り、リーダーは通常それをサポートします。ただし、メンテナンスソフトウェアを作成したい場合、投資額が大きく、直接的な経済的利益は得られないため、リソースを取得できるかどうかは不明です。
デバッグ作業がとても大変だったことを覚えていますが、特定の変数を観察したい場合は、LCD出力インターフェイスを一時的に変更する必要があります。時間がかかるだけでなく、制限もあります。多くの変数を同時に観察したい場合は、さらに困難です。他の変数を観察したい場合は、プログラムを変更して再試行する必要があります。
プロトコルのデバッグ中に、プロジェクトチームのカスタムプロトコルであり、外部の力の助けを借りたチャネルでさえブロックされていたため、デバッグ手段がないことがわかりました。どうしようもなく、VCとMFCのフレームワークを使用して簡単なダイアログをすばやく作成しました。これは手動のフレーミングですが、少なくとも簡単なデバッグ環境が構築されています。
その後、デバッグする必要のある関数が増え、ダイアログボックスが適合しなくなりました。インターフェイスの再編成を余儀なくされました。Outlookは左側のコントロールをトリガーしました。右側のトラブルを回避するために、フォームに同意しました。
現時点で、他のプロジェクトチームは、私たちにこれほど優れたものがあり、すぐにそれを使用したいと考えていました。しかし、その願いは美しく、現実には残酷です。私の粗末なバージョンのメンテナンスソフトウェアは、特定の製品に固く拘束されており、まったく動かないことがわかります。
さらに奇妙なのは、ソフトウェアをメンテナンスしないと会社がリソースを提供しないことですが、大まかなバージョンを入手すると、誰もがソフトウェアのメンテナンスを完了したと思い込み、さまざまなニーズがすぐに続き、人々は悲惨になります。言葉。
構成ソフトウェアと比較して、メンテナンスソフトウェアは幸運です。結局のところ、追加のメンテナンスソフトウェアをユーザーに無料で提供している会社は常に存在します。豚のランを見たことはありませんが、常に豚肉を食べてきたので、誰もが時間があるときはいつでもビルドしようとしています。メンテナンスソフトウェアですが、誰もが長い間、構成ソフトウェアの価値を理解していませんでした。
初期の製品開発では、多くの製品のデータの不整合に直面することがよくありました。当時は、さまざまなデータテーブルを手動で作成するのに慣れていました。その後、LCDモジュールで漢字を調整する必要が生じたとき、全員が協力して小さなプログラムを作成していました。GUIモジュールを描画する必要があったときLCDインターフェイスの場合、MFCクラスライブラリのdrawCliルーチンに基づいて小さなプログラムをすばやく作成しました。つまり、すべての動作は受動的で潜在意識があり、アーキテクチャ全体に対するこれらの小さなプログラムの重要性について積極的に考えたことはありません。
多国籍企業の研究開発中に、アーキテクトによるプログラムフレームワークの説明を聞くとき、多くの場合、構成ソフトウェアとメンテナンスソフトウェア、特に中核となる構成ソフトウェアについて言及するのは自然なことです。それは蓄積の結果かもしれないし、インスピレーションに溶け込んだ過去の苦しい経験が突然、突然のひらめきを感じさせた。それ以来、私の考えでは、ソフトウェアの構成と保守はもはや必須の役割ではなく、アーキテクチャーの有機的な部分です。
◇◇◇
アーキテクチャ全体の観点から見ると、構成ソフトウェアは、統合プラットフォーム上の製品間の違いを埋めるために使用され、研究開発段階でサポートするソフトウェアです。
過去に無意識に作成したあらゆる種類の小さなプログラムは、漢字ライブラリの抽出やLCDインターフェイスの描画など、構成ソフトウェアのカテゴリに属します。しかし、構成ソフトウェアが個別の概念として洗練されれば、多くの新しい価値が生まれます。
非常に古典的な例は文字列です。組み込みシステムでは、以下に示すように、文字列の長さは設定値構造を保護するために非常に厄介です。
struct TSetting
{
char szName[32]; /* 定值名称 */
char szDescribe[64]; /* 定值描述 */
......
}
固定値の名前は32文字の文字列で、最大16文字の漢字であることに同意します。一般的にはこの長さで十分ですが、毎年十分ではない特別な状況が常にあり、より多くの本物の顧客に出会うと、誰もがかなり困惑します。名前だけが適切で、固定値の説明情報はより扱いにくいものです。それらのほとんどはそれを必要としませんが、いくつかはより長い文字列を必要とします。（注：上記の構造では、名前の最初の説明にプログラムテクニックが含まれています。特定のフィールド値の名前が長すぎる場合は、固定値の説明の部分を占有できます。このとき、固定値の説明は固定値の名前と同じであることに同意できます）
固定値の名前または説明のほとんどは静的文字列です。より独創的な戦略は、すべての文字列情報を圧縮して保存し、これらの文字列にインデックスでアクセスすることです。このときの構造は次のとおりです。
struct TSetting
{
WORD wName; /* 定值名称 */
WORD wDescribe; /* 定值描述 */
......
}
この戦略によりフラッシュリソースが大幅に節約されますが、この効果を達成するには、製品全体で使用されるすべての静的文字列情報を収集、要約、および重複除外する必要があります。文字列情報は、固定値、液晶インターフェースなどのほぼすべてのモジュールに配布されます。統合構成ソフトウェアが存在する前に、これはほとんど不可能です。
別の例はバイトオーダーの問題で、チップによってバイトオーダーが異なり、主にビッグエンディアンモードとリトルエンディアンモードが含まれます。元のデバイスが特定のパラメータファイルを受け取った後、使用する前にバイトオーダーを再調整する必要があります。構成ソフトウェアのサポートにより、特定のバイトオーダーでパラメーターファイルを直接生成できます。現時点では、デバイスはバイトオーダーを調整する必要がなく、フラッシュからRAMスペースにパラメーターファイルをコピーする必要もありません。ポインターのマッピングを完了するだけです。
多くの国際的な製品には、数十万ページの厚いマニュアルがあります。これは、私自身の製品の貧弱な数十のマニュアルに比べると恥ずかしいです。多国籍企業の研究開発の経験の中で、これらの分厚いマニュアルがどのように作成されるかがようやくわかりました。付録のほとんどは設定ソフトウェアによって自動的に生成され、実際の人が書いた部分は私たちのものとそれほど変わりません。
通常、製造元のマニュアルに付録が厚い場合は、プログラムアーキテクチャレベルが特定のレベルにまで反復されている可能性が高いことに注意してください。これらの会社の製品品質も比較的高いはずです。入社にも適しています。
高度な再利用と厳密なプラットフォームベースのアーキテクチャの継続的な反復により、構成ソフトウェアにはより多くの機能が与えられます。たとえば、私が参加したプロジェクトでは、さまざまな再利用可能なモジュールを抽出して構成テーブルを自動的に生成し、プログラムが複数のCPUに分散されている場合はCPU間の通信構成テーブルを自動的に生成し、ユーザーマニュアルの付録を自動的に生成しました。
建築家は、構成ソフトウェアの高さがアーキテクチャ設計の高さを決定することをしばしば嘆いたことを覚えています。私のかなり粗末な構成ソフトウェアを見て、2つを比較すると、幸いにも、まだ成長の余地がたくさんあります> _ <。
◇◇◇
初期の頃、私の心のメンテナンスソフトウェアは、私たち自身がたまに使用する補助ソフトウェアでした。せいぜい、それはエンジニアが現場の機器をデバッグするのを助けるために使用されました。メンテナンスソフトウェアをアーキテクチャ設計の個別の部分として検討した後、メンテナンスソフトウェアの範囲が拡大されます。構成ソフトウェアが開発段階のソフトウェアである場合、メンテナンスソフトウェアは完成品のソフトウェアです。
工業製品は一般に信頼性に対する非常に高い要件があり、テストは常に頭痛の種でした。テストのワークロードを削減するために、自動化されたテストを通じて多くの繰り返しテスト作業を完了します。自動テストフレームワークを構築するには、ソフトウェアの連携を維持する必要があります。
マイクロコンピューター保護の自動テストなど、特定の電気量を追加するためにリレーテスターをトリガーするメンテナンスソフトウェアを介して、リレー保護テレメトリ値を読み取ることで、計算精度を簡単に判断できます。さまざまな電気出力検証プロセスをスクリプトに編成でき、レポートを自動的に生成できる場合は、自動テスト環境が構築されています。
テストをガイドできるようになったので、本番環境をガイドできます。ハードウェアには常に違いがあり、デバイスが出荷されるときに係数の修正が必要です。これは、忍耐力を必要とし、非常に退屈な作業です。たとえば、メンテナンスソフトウェアが自動的にトリガーして自動係数補正を実行します。これは効率的であるだけでなく、手動キャリブレーションよりも正確です。
これらはメンテナンスソフトの主要な機能と言え、多国籍企業の研究開発の経験に心を打たれたのが、メンテナンスソフトをベースとした二次開発環境です。このようにして生産された製品は、高度に再利用されたソフトウェアモジュールやスクリプトなどの戦略に基づいて、強力な二次エンジニアリングカスタマイズ機能を備えています。プラットフォーム、製品、エンジニアリングの3層R＆Dシステムに基づいて、多くの特別な要件を現場で完了することができます。
ハードウェアの急速な開発にもかかわらず、多国籍企業は本社で一般的な製品の研究開発のみを行うことができ、その後、さまざまな地元企業の担当者が特定の製品の研究開発を完了することができ、それぞれが独自の利点を最大限に発揮します。私が率いるチームは、そのようなカスタマイズされた多くの開発タスクを完了しました。
要件の継続的な反復により、メンテナンスソフトウェアは単純なダイアログボックスから複雑なソフトウェアモジュールに進化することができました。
◇◇◇
蓄積して開発した後の瞬間的な洞察は、構成ソフトウェアと保守ソフトウェアを再理解するのに役立ちますが、これら2つのソフトウェアを自動的に構築するのには役立ちません。現実世界は役に立たないことがよくあります。人員が不足し、時間が短く、重いタスクがあり、短期的なメリットはありません。多くの要因により、会社は構成とメンテナンスのためのソフトウェアを個別に開発するためのリソースを投資できないと判断しています。すべての作業は製品開発の過程で行われなければなりませんが、さまざまな複雑な機能に直面して、人々はしばしば無力感を感じます。
この問題を解決するには？上記のように、私が採用する戦略は「人を借りる」ことです。私は通常、会社の採用、トレーニング、その他の多くのタスクを引き受けますが、職場での最良のトレーニングは、学ぶことではなく、使用することであることをよく知っています。これらの新参者の力を借りて、構成ソフトウェアと保守ソフトウェアを構築できますか？
初心者がすぐに成長できるようにするには、プログラミング仕様のトレーニングを完了した後、誰もが自分の記憶を深める小さなプログラムを書く必要があります。ただし、初心者は能力が限られているため、複雑なアーキテクチャ製品に直面することはできません。純粋なソフトウェアモジュールであることが最善です。メンテナンスソフトウェアと構成ソフトウェアは、多くの断片的な機能で構成されているため、適切なソフトウェアアーキテクチャを構築して、新規参入者がこれらの断片的な機能を実行できるようにすることは、良い戦略です。
幸い、私はそれをしました。
◇◇◇
多国籍企業が研究開発を始めたとき、構成ソフトウェアと保守ソフトウェアはまったく別のソフトウェアでしたが、実際、これら2つのソフトウェアは2つのまったく別のチームによって完成されました。このソフトウェアを1つに統合できますか？
構成ソフトウェアと保守ソフトウェアを統合する場合は、最初にインターフェースを統合する必要があります。さまざまな要因を考慮すると、統一されたインターフェースの図は次のようになります。
特定のインターフェースの例は次のとおりです。
インターフェース全体が3つの部分に分かれており、トップレベルはメニューバーとツールバーであり、構成ソフトウェアのパラメーター生成、メンテナンスソフトウェアなどのグローバル機能に焦点を当てています通信接続など、特定の機能に関連するメニュー項目を含まないように注意してください。
左側のツリービューは、構成ソフトウェアのさまざまな構成サブノードやさまざまなメンテナンスソフトウェア機能などの情報の整理に使用されます。ツリービューはxml形式で構成されています。これにより、インターフェイスの柔軟性が確保されるだけでなく、プログラムモジュールの結合が減少します。
xml形式は次のとおりです。
<?xml version="1.0"?>
<funtree>
<fun name="对时" class="CSystemTimeFun" ……/>
<dir name="查询">
<fun name="遥测" class="CReadAIFun" ……/>
<fun name="电度" class="CCIFun" ……/>
<fun name="遥信" class="CYXFun" ……/>
</dir>
</funtree>
右側の上半分は特定のインターフェースであり、各インターフェースは左側のノードタイプに関連しており、設定インターフェースまたはメンテナンスインターフェースのいずれかになります。複数のインターフェイスを共存させ、タブモードで整理できます。インターフェイスの再利用のために、テーブルやプロパティページなどの複数のインターフェイススタイルが、サブクラス化用にデフォルトで提供されています。一部の特定の機能インターフェースには、追加のメニューまたはツールバーが必要です。これらは、サブインターフェースの上部に均一に配置されます。
右側の下半分はログビューで、さまざまな操作レコード、パラメーター解析エラーメッセージ、クエリレコード、プロトコルフレーム、およびその他の関数をプロンプトするために使用されます。これらの関数のほとんどはフレームワークによって提供されます。
はじめに「MFC Explained in Simple」という本を読んだとき、MFCクラスライブラリには一連のマクロ定義があり、文字列情報に基づいてクラスを直接作成できることがわかりました。これは、左側の特定のツリーノードをクリックするのと同じです。特定のインターフェイスを直接作成して右上に表示できます。これは、上部のプログラムを知らなくても、フレームワークプログラムの部分と同じです。xml構成情報のclass属性がクラス名の設定に使用されていることに気づきましたか。
私は自分の手をかゆみ、MFCマクロメカニズムを個別に改良しました。当時、世界は2000世紀の新年を祝っていました。このマクロ名のセットを2000と定義しました。NとZはどちらもいたずら2です！コード例は次のとおりです。
/*****************************************************/
/* .h文件部分 */
/*****************************************************/
//支持动态创建,做法同MFC类库
class CFunBase;
struct CRunNZNClass
{
QString m_lpszClassName;
CFunBase* (*m_pfnCreateObject)();
CRunNZNClass* m_pNextClass;
static CRunNZNClass* m_pFirstClass;
static CRunNZNClass* load(QString lpszClassName);
CFunBase* createObject();
};
struct CRunNZNClassInit{CRunNZNClassInit(CRunNZNClass* pNewClass);};
#define DECLARE_FUN(class_name) \
public: \
static CRunNZNClass _nzn_##class_name; \
virtual CRunNZNClass* getRunNZNClass() const; \
static CFunBase* createObject();
#define IMPLEMENT_FUN(class_name) \
CRunNZNClass class_name::_nzn_##class_name = { \
#class_name, \
class_name::createObject, \
NULL \
}; \
static CRunNZNClassInit _init_##class_name(&class_name::_nzn_##class_name); \
CRunNZNClass* class_name::getRunNZNClass() const \
{ return &class_name::_nzn_##class_name; } \
CFunBase* class_name::createObject() \
{ return new class_name; }
/*****************************************************/
/* .cpp文件部分 */
/*****************************************************/
CRunNZNClass* CRunNZNClass::m_pFirstClass = 0;
CRunNZNClass* CRunNZNClass::load(QString lpszClassName)
{
CRunNZNClass* pClass = 0;
for (pClass = m_pFirstClass; pClass != NULL; pClass = pClass->m_pNextClass)
{
if (lpszClassName == pClass->m_lpszClassName)
return pClass;
}
return 0;
}
CFunBase* CRunNZNClass::createObject()
{
if (m_pfnCreateObject == 0)
return 0;
CFunBase* pFunBaseObject = 0;
pFunBaseObject = (*m_pfnCreateObject)();
return pFunBaseObject;
}
CRunNZNClassInit::CRunNZNClassInit(CRunNZNClass* pNewClass)
{
pNewClass->m_pNextClass = CRunNZNClass::m_pFirstClass;
CRunNZNClass::m_pFirstClass = pNewClass;
}
スペースの制限のため、このコードセットの具体的な詳細については詳しく説明しませんが、興味がある場合は、「MFC Explained in Simple」という本を参照してください。この一連の魔法のマクロの助けを借りて、各新規参入者のエクササイズコードを直接使用できます。単にxmlファイルを変更するだけです。
◇◇◇
構成ソフトウェアの主な機能は、製品の属性を均一に構成し、検証後にさまざまなコード、パラメーター、ドキュメントなどを生成することです。特定の実装では、「統合構成と分散リリース」の戦略を採用することに慣れています。この戦略を使用する最大の利点は、固定値と液晶インターフェースの統合構成など、情報のインタラクティブなインデックスを減らすことです。固定値の名前の文字列情報は、固定値の液晶インターフェース構造に直接使用できます。複数の構成ソフトウェアに分割されている場合は、相互にインデックスを付けるパラメーターを生成する必要があります。
構成ファイルはもともとデータベースを使用していましたが、後でJSON形式に調整されました。デバイスのさまざまな構成情報は当然ツリー構造として表示されるため、JSON形式の方が適しています。さらに重要なことに、データベースは統一された方法で編成する必要があり、JSON形式を自然に拡張して、各モジュールの独立した編成と全体的な再利用を促進できます。
構成ソフトウェアの中でさらに複雑な部分は、パラメータの合法性検証部分で、各ノード自体の検証は難しくありませんが、グローバルな情報を必要とする検証項目は難しいです。この種の検証機能をサポートするために、すべての情報に基づいてクエリマッピングテーブルを構築し、これらの複雑な検証モジュールを個別に抽象化できるコンパイルシステムの「パス」の概念を利用します。
メンテナンスソフトウェアで追加される主な機能項目は、設定ソフトウェアと比較して通信とプロトコルですが、一般にシリアルポート、イーサネット、仮想デバイス通信など、さまざまな通信機能とプロトコルを提供する必要があります。設定ソフトウェアの全体的なアーキテクチャ図は次のとおりです。
◇◇◇
保守ソフトウェアと構成ソフトウェアの設計の詳細は、それらが詳細に説明されている場合、独立した本であると推定されます。この章はスペースに制限があり、プログラムアーキテクチャの観点から構成ソフトウェアとメンテナンスソフトウェアをすべての人に再理解させることに重点を置いています。知識が整っている限り、構成ソフトウェアとメンテナンスソフトウェアは非常に手間がかかりますが、アーキテクチャの設計自体は難しくありません。
——————————————
私はXiaomaerです。良心と魂を切望する組み込みソフトウェアエンジニアです。あなたの会社を歓迎し、旅行してください。興味がある場合は、個人のWeChat アカウントnzn_xiaomaerを追加して通信することができます。「異次元」という言葉に注意する必要があります。