Operational Client
Full graphical user interface for daily operator activities.
Configuration Client
Enjoy custom configuration with our Config Client.
WEB Client
Provides remote web access to our core services.
GIS Integrations
Intuitive visualization of mobile units and alarms.
Incident Manager
Helps you handle incoming notifications efficiently.
IP-Matrix
With our IP-Matrix, you can control your video walls.
Tout d'abord, voyons ce que Wikipédia a à dire sur les deux :
API “Une interface de programmation d'application (API) est un ensemble de fonctions, procédures, méthodes ou classes utilisées par des programmes informatiques pour demander des services au système d'exploitation, aux bibliothèques de logiciels ou à tout autre fournisseur de services fonctionnant sur l'ordinateur."
Protocole “En télécommunication, un protocole de communication est un système de règles qui permettent à deux entités ou plus d'un système de communication de transmettre des informations via tout type de variation d'une quantité physique".
Après avoir parcouru des tonnes d'articles et de forums sur les différences entre l'API et les protocoles, vous pourriez commencer à penser qu'il s'agit plus ou moins de la même chose, expliquée avec des mots différents. En effet, ils sont tous deux nécessaires pour créer une communication entre deux ou plusieurs systèmes, ce qui entraîne une confusion.
Pour commencer, il faut savoir exactement ce qu'il faut imaginer lorsque l'on parle d'un protocole de communication. Prenons par exemple l'un des protocoles de gestion de bâtiment les plus connus: BACnet. BACnet ( B uilding A utomation and C ontrol net work) a été conçu pour automatiser les systèmes du bâtiment tels que le chauffage, la ventilation, le CVC, le contrôle de l'éclairage, le contrôle d'accès et la détection d'incendie.
En suivant les règles BACnet, il est possible pour une plateforme logicielle d'intégration, de communiquer avec plusieurs systèmes du bâtiment, le tout à partir d'une interface centrale. Même si tous les systèmes sont produits par des fournisseurs différents, les connexions avec tous ces systèmes sont toujours possibles via BACnet, ce qui est extrêmement efficace pour les grandes entreprises.
Maintenant, quelle est la différence entre un protocole de communication et une API? Eh bien, l'API utilise le protocole afin d'extraire les informations exactes nécessaires pour effectuer certaines tâches. Disons que vous êtes un opérateur dans une salle de contrôle. Sur la caméra, vous voyez que dans une certaine salle de réunion, les lumières sont toujours allumées pendant que la réunion est terminée. L'opérateur éteint ensuite ces lumières via l'application logicielle d'intégration. Pour cette tâche apparemment simple, plusieurs actions sont menées.
Par exemple, nos développeurs ont intégré une API dans Sky-Walker qui demande au système d'éclairage physique d'éteindre les lumières, après quoi le système d'éclairage répond à Sky-Walker que les lumières ont été éteintes. Et la langue dans laquelle ils demandent et répondent? Vous l'avez deviné, le protocole BACnet.
Un terme que nous rencontrons souvent concernant les protocoles de communication et les API est un SDK. Un SDK signifie S oftware D éveloppement K il. Regardez les images ci-dessous pour voir comment une API et un SDK sont liés.
Comme vous pouvez le voir, l'API fait partie du SDK. En règle générale, tous les SDK contiennent des API, mais toutes les API ne font pas partie des SDK. Un SDK est un ensemble complet d'une ou de plusieurs API et d'outils supplémentaires tels que du matériel de test, une version de démonstration, une documentation complète, etc. Avec un SDK, le développeur est capable de créer toutes les applications nécessaires à certaines tâches. C'est plus ou moins le package complet lors de la connexion d'un autre type de système au logiciel. C'est aussi le paquet d'informations préféré d'un développeur, bien sûr.
Les protocoles sont de deux types différents, ils peuvent être ouverts ou propriétaires. Chacun d'eux a ses avantages et ses inconvénients. Les protocoles ouverts sont disponibles gratuitement pour tous. De plus, ils sont très bien documentés car de nombreux systèmes les utilisent. Cela se traduit par de nombreux forums sur la résolution de problèmes. Ils peuvent être faciles à utiliser et gratuits, mais en revanche, ils présentent plus de risques pour la sécurité, car tout le monde peut apprendre comment ces systèmes communiquent. Dans le secteur PSIM, la sécurité est la force clé des logiciels, les systèmes sont donc souvent accompagnés d'un protocole propriétaire.
Par conséquent, certaines entreprises produisent des systèmes qui utilisent des protocoles propriétaires. Ces protocoles sont très spécifiques pour un ensemble de fonctionnalités. Comme peu de gens les utilisent, ils sont également plus sûrs à utiliser. L'un des plus gros inconvénients des protocoles de propriété est qu'ils coûtent souvent de l'argent. En outre, les informations recueillies doivent rester privées, souvent contrôlées par un NDA (Non Disclosure Agreement).
Certains protocoles ouverts typiques sont Modbus, Bacnet, OpenTouch, OPC, HTTP, FTP et SIA. Certains des protocoles propriétaires typiques sont Notifier et Flex par exemple.
Lorsqu'un nouveau système doit être connecté à une interface, disons notre plate-forme d'intégration ouverte Sky-Walker par exemple, un protocole pour ce système spécifique doit souvent être demandé. Vous trouverez ci-dessous un organigramme d'une demande de protocole typique, et comme vous pouvez le voir, ce n'est pas toujours aussi simple !