Cookwala

Cette page a été traduite par une machine et n'a pas encore été révisée par une personne. L'anglais est la référence ; les corrections sont les bienvenues sur GitHub. GitHub

Cookwala / For

Pour les fabricants d'appareils : fours, plaques, multicuiseurs, robots de cuisine et humanoïdes

Un appareil qui implémente Cookwala lit une recette signée, vérifie chaque étape contre ce qu'il sait faire et mesurer, refuse ce qu'il ne peut pas vérifier avant que quoi que ce soit ne chauffe, et garde ses propres limites de sécurité quoi qu'en disent la recette, l'agent ou le réseau. Cinq points d'accès, un document de capacités, des tests publics.

Pourquoi cela vous importe

Vous possédez déjà la partie difficile : le mouvement, le contrôle de la chaleur, les capteurs. Cookwala vous donne la couche tâche au-dessus, ouverte et sans redevance : un format de recette qu'une machine peut planifier, des enveloppes d'opération avec des bandes physiques, une échelle de capteurs par étape, des limites de sécurité locales que rien ne peut relever, et un refus qui est une réponse normale, pas une erreur. Vos clients obtiennent toutes les cuisines sans que vous écriviez une recette ; votre régulateur obtient une histoire de sécurité lisible ; vos commerciaux obtiennent un rapport de conformité signé plutôt qu'une affirmation.

Ce qui existe aujourd'hui : l'API Core 0.2, un exécuteur de référence à faire tourner à côté du vôtre, 51 vecteurs de conformité Core dont les dry runs d'exécuteur, un format de rapport signé et un vérificateur. Ce qui n'existe pas : un certificateur, un test matériel, une deuxième implémentation. Vous seriez le premier, et la norme changerait là où vous montrez qu'elle a tort.

Approches, de la plus légère à la plus profonde

  1. Léger. Écrivez un document de capacités pour un produit et faites un dry run des neuf recettes d'exemple dessus, dans le navigateur ou en ligne de commande ; lisez les sections 3 et 6 de Core 0.2 en une soirée.
  2. Moyen. Implémentez les cinq points d'accès Core sur un hub à côté de votre firmware, lancez les suites exécuteur, démarrez le hub de référence avec un jeton et comparez les réponses sur le réseau.
  3. Profond. Appliquez le paquet de limites de sécurité sur l'appareil, mesurez l'arrêt local, publiez un rapport de conformité signé, ouvrez une pull request qui l'inscrit au registre, et dites-nous quoi changer dans Core 0.3.

Premier succès, en moins de 15 minutes

Moins de 15 minutes, sans matériel : lancez les suites exécuteur, puis faites un dry run d'une recette contre votre propre document de capacités.

git clone https://github.com/amado2k5/cookwala && cd cookwala && pip install -e sdk/python
python tools/run_conformance.py envelope   # 14 vectors: bands, altitude, sensor ladders
python tools/run_conformance.py dryrun     # 7 vectors: refusal before heat
cp examples/capabilities/robot-arm.json my-device.json   # edit ops, sensors, safety
cookwala dryrun examples/koshari.cookwala.json --device my-device.json --human-present
conformance: 14/14 passed · conformance: 7/7 passed · accepted or refused with the step and the reason

Le chemin après cela

  1. Écrire le document de capacités : opérations, capteurs avec leur précision, sécurité (certifications, détection de présence, arrêt)
  2. Faire un dry run des recettes d'exemple ; chaque refus nomme l'étape et la raison
  3. Implémenter POST /v1/executions, GET status, stop, resume et le journal, plus GET /v1/capabilities et /v1/safety-limits
  4. Lancer les suites exécuteur (envelope, dryrun, transitions) et les vérifications réseau du README du hub
  5. Publier un rapport de conformité signé ; en attendant un service de registre, une pull request l'ajoute au fichier du registre
  6. Rien n'est encore certifié : aucun certificateur n'existe, et le rapport dit ce qu'il prouve et ce qu'il ne prouve pas

Autres voies