開発範囲
デバイスとインターフェースへのアクセス
貨物レーン、出荷検出、ドアのステータス、在庫インターフェースに適応し、支払い結果、注文番号、機器の実行の間のマッピングを確立します。
製品のビジネス機能
商品レーン、支払い結果、機器センサーを接続して、注文ステータス、出荷検証、例外補償、在庫、リモート診断を開発します。
プラットフォームとデータ接続
注文または認可→ローカル状態チェック→デバイス実行→4G結果返却→注文および保守管理というビジネスリンクと組み合わせて、デバイスID、データフィールド、更新時間、例外ステータス、結果確認方法が定義されます。
例外処理と操作上の制約
支払い結果と発送結果は別々に確認する必要があります。返金や補償は顧客の認証プラットフォームのプロセスに従って処理され、繰り返しの注文によって繰り返し出荷が行われてはなりません。
データと運用のワークフロー
プラットフォームの注文確認 → 4G 経由で販売コマンドを送信 → 販売チャネルの作動と検出 → 結果の確認 → 在庫と異常な注文の処理。
デバイス側、通信側、プラットフォーム側でそれぞれ必要なステータスとログを保持します。プロジェクト結合テストは実機データと実行結果を確認し、ネットワーク接続状況と業務完了状況を分けて記録します。
プロジェクト開始に必要な資料
- 既存のデバイス モデル、インターフェイスおよび配線図、ライセンス契約、データ サンプル、および利用可能なコード。
- ビジネス プロセスとパラメータ: 貨物レーンと出荷の検出、注文の識別、在庫ルールと例外補償。
- 対象場所、事業者、SIM/APN、電源、設置方法、機器サイズ。
- 既存のプラットフォーム インターフェイス、ユーザーの役割、開発モジュール、プロトタイプの数、および計画されているノード。
成果物と検収
| 成果物 | 配信内容 | 検証方法 |
|---|---|---|
| 製品の実現 | プロジェクトに関係するハードウェア設計データ、プロトタイプまたは既存の機器の変更データ、および対応するファームウェアとインターフェース | 正常な出荷品、滞留品をテストし、異常を検出します。 |
| 経営統合テスト | データフィールド、ステータス定義、プラットフォーム適応手順、およびビジネス統合テスト記録 | 注文の重複、タイムアウト、再接続の回復を確認します。 |
| バージョンとテストデータ | ターゲットのハードウェアとソフトウェアのバージョン、構築または展開の手順、パラメータ構成、およびテスト ログ | 在庫の変更と注文結果の整合性を確認します。 |
まず範囲と主要な機能を確認し、次にプロトタイプまたはソフトウェアの開発、システム統合テスト、および段階的な承認を完了します。受け入れ条件には、プロトタイプ、バージョン、環境、期間、および合格しきい値がリストされています。ソース コード、設計ドキュメント、サードパーティ ライセンス、マテリアル、トラフィック、クラウド リソース、およびオンサイトでの作業については、個別に合意されます。
よくある質問
切断と再接続により出荷が繰り返されることになりますか?+
端末とプラットフォームは、一意の注文識別子に従って実行ステータスを保存し、再試行およびクエリのプロセスを定義する必要があります。ネットワークを復旧する場合は、結果を確認してから作業を続行するかどうかを判断してください。特定の動作は、障害の使用例を通じて検証されます。
自動販売機のコントロールパネルの機能の一部だけを委任することはできますか?+
デバイスインターフェイス、端末プログラム、4G通信、プラットフォーム統合テストは、既存の研究開発基盤に基づいて分割できます。既存の情報とターゲットの境界を提供し、最初に「貨物レーンと出荷の検出、注文の識別、在庫ルールと例外補償」を確認し、次に各モジュールの成果物とインターフェイスの責任を明確にしてください。
コストとサイクルタイムはどのように評価されますか?+
ターゲット デバイス、インターフェイス、既存のデータ、検証基準に基づいてワークロードを分割します。このプロジェクトは、貨物レーンのチェックと出荷検査、注文の識別、在庫ルールと異常補償に重点を置いています。プロトタイプ、オンサイト統合テスト、またはサードパーティ プラットフォームとの連携が必要な場合、対応するコスト、前提条件、およびノードは個別にリストされます。
相談
電話
WeChat
トップに戻る