L’évaluation de l’intégration nécessite les appareils et protocoles d’application réels des deux côtés. Un nom de marque ou une déclaration indiquant que CAN est pris en charge ne suffit pas. Répertoriez les documents disponibles, les entrées manquantes et les conditions de test pour séparer l'analyse du protocole, le micrologiciel de la carte client et le travail d'intégration des appareils.
Liste de contrôle des contributions au projet
| Groupe d'entrée | Informations requises | Décision appuyée |
|---|---|---|
| Identité de l'équipement | Modèles de batterie, BMS ou BMU et d'onduleur et firmware, connexions système | Applicabilité du protocole et différences de version |
| Protocoles d'application | Documents réels en CAN, versions, définitions de champs et utilisation autorisée | Décodage de trame, limites et mappage d'état |
| Interface électrique | Brochage, alimentation, masse de référence, terminaison, faisceau et isolation | Sélection des cartes et conditions de connexion |
| Échantillons bruts | Messages horodatés, configuration et conditions de fonctionnement connues | Champs, timing, signes et comportement de démarrage |
| Carte et logiciel | Schémas, contrôleurs et émetteurs-récepteurs, SDK, pilotes et code existant | Implémentation du micrologiciel et ressources d'interface |
| Tests et livrables | Appareils et personnel disponibles, périmètre opérationnel, jalons et critères de réussite | Plan d'intégration, acceptation et limites de coûts |
Comment confirmer les documents du protocole
Vérifiez l'interface, la version et les modèles applicables indiqués dans chaque document. Un document RS485 ne remplace pas un protocole d'application CAN, et des noms de protocole similaires n'établissent pas la même version. Les déclarations de marque, de modèle et de compatibilité dans les diagrammes de référence nécessitent une confirmation par rapport aux appareils réels et aux enregistrements de test. Pour les documents de fabricant restreints, convenez de l’utilisation autorisée et examinez les modalités avant de les partager.
Que peut-on commencer avec des entrées incomplètes ?
Le travail initial peut inclure un registre des lacunes d'entrée, un examen des ressources d'interface, une analyse des messages disponibles et un plan de prototype limité. Les limites, états ou définitions de délai d'attente manquants laissent les fonctions correspondantes non confirmées. Les tests sur simulateur et l’intégration des appareils sont des étapes distinctes lorsque l’équipement n’est pas disponible. Un devis doit distinguer le travail exécutable, le travail dépendant d'entrées supplémentaires et les coûts d'échantillonnage ou de test.
Geler les versions d'entrée avant l'acceptation
Liez la liste de livraison aux versions de l'appareil, du protocole, de la carte et du micrologiciel, en conservant les cas de test et les problèmes en suspens. Un modèle d'onduleur différent, une mise à jour du micrologiciel, un changement de message ou une carte de remplacement nécessitent une analyse d'impact et des tests de régression pertinents. Une combinaison d'appareils antérieure ne valide pas automatiquement le système modifié.
En ligne
Téléphone
WeChat
retour au sommet
Commentaires sur le projet
Winge voltooit headless OpenHarmony 6.1 Fase 0-verificatie op RK3588
MijlpaalBuild22 startte Linux 5.10.210 en OpenHarmony init vanaf SD, koppelde rootfs, /vendor en /data aan, leverde een ···
OpenHarmony 6.1 Systeemaanpassing fase 0 naar RK3588
Direct antwoordOnder de gespecificeerde projectomstandigheden startte OpenHarmony 6.1 de kernel RK3588 op en initeerde O···
Winge ดำเนินการตรวจสอบแบบไม่มีหัว OpenHarmony 6.1 ขั้นที่ 0 เมื่อวันที่ RK3588
เหตุการณ์สำคัญBuild22 เริ่มต้น Linux 5.10.210 และ OpenHarmony เริ่มต้นจาก SD, rootfs ที่เมาท์ /vendor และ /data จัดให้มี···