2010-11-18 58 views
16

Necesito crear un proceso de CM para el código del PLC.PLC Version Control

Actualmente, el sistema se desarrolla con RSLogix 5000. El producto de compilación es un archivo monolítico que puede cargarse en un PLC para su ejecución y editarse directamente en el entorno de desarrollo. Con múltiples desarrolladores, esto se ha convertido en un problema. Están pisando los cambios de los demás.

Como analogía, es como si, al hacer el desarrollo de Java, la única manera de editar y guardar la fuente fuera cargar un archivo * .jar en su IDE, realizar el cambio y luego guardarlo nuevamente en el archivo jar Esto es menos que ideal.

¿Cómo puedo coordinar los cambios entre varios desarrolladores que trabajan con PLC?

+0

¿Qué tipo de solución se te ocurrió? Estamos teniendo el mismo problema con mantener todos los archivos de los programadores actualizados. – JMooney

+0

@JMooney: Simplemente me mantuve confundido. – Dave

Respuesta

5

Si hablamos de un gran archivo binario, entonces un VCS (centralizado o descentralizado) no es la mejor herramienta para el trabajo.
Una referencia externa (un disco compartido, por ejemplo) donde un lote copiará y etiquetará el estado PCL actual es mejor.
Ver "Tracking Software History"

para evitar discontinuidades en el registro histórico de revisiones, versiones anteriores de los programas deben ser almacenados.
"Sin embargo, damos un paso más. Usando nuestro MDT AutoSave, en realidad salimos e interrogamos al equipo. De la noche a la mañana o a la frecuencia especificada, el software lee los programas en los PLC y luego compara esa información con el último programa conocido. El software de control de versiones copiará el nuevo programa y lo almacenará y [luego] lo comparará con el último.

La ejecución del control de versiones es bastante simple. Se requiere instalación de software y luego configuración de hardware. "Necesitarías un servidor y un par de semanas de ingeniería y estarás listo", dice Perysyn. Sin embargo, su empresa utiliza un "enfoque de envoltura retráctil" que involucra la instalación del software y la personalización por parte de los usuarios que rellenan los espacios en blanco.

Dicho esto, cuando se tienen varios cambios con respecto a varios desarrolladores, es necesario un entorno integración, donde una primera entrega se puede hacer y se valida, antes de empujarlo al servidor real.

Véase también this post.

+1

Gracias. Has confirmado mis temores :) – Dave

4

Esta es una muy buena pregunta y realmente depende de lo que quieras que haga. Si solo está utilizando el equipo de Rockwell podría ser útil analizar su solución, creo que se llama FactoryTalk AssetCentre. Actualmente estoy buscando usar Bazar de Canonical. Una cosa que VonC señaló es que una pieza de software que puede intercalar el PLC es una ventaja adicional, no es una obligación en mi opinión, pero seguro que ayuda.

¿Estoy leyendo su pregunta correctamente y tiene varios desarrolladores trabajando con el mismo código de PLC al mismo tiempo? Es una idea aterradora, pero sé que a veces debe suceder, los PLC de Siemens son un poco más fáciles de programar con múltiples desarrolladores, pero yo asignaría a una persona para consolidar y probar todos los cambios antes de comprometerse con el PLC. Cualquier sistema de CVS le permitirá crear sucursales para cada desarrollador, pero la forma en que los conseguiría para consolidar sus cambios es la pregunta del millón de dolares.

Bart.

+0

No soy un codificador de PLC, así que no puedo decir definitivamente que están trabajando en el * mismo * código, es decir, ambos trabajando en Foo.java al mismo tiempo, pero thay Definitivamente están intentando extraer Foo.java y Bar.java de forma independiente de Baz.jar, hacer sus respectivos cambios y luego verificar de forma independiente en Baz.jar. ¿Tiene sentido esa analogía? – Dave

+0

Es exactamente el mismo problema que ves con PowerBuilder y los archivos * .pbl. – Dave

+0

Lo siento, debería haber aclarado que me refería a trabajar en el mismo archivo pero en diferentes secciones del código. Si está programando un PLC con RSLogix, tiene un archivo (.ACD) pero este archivo contiene la configuración del PLC, el código para diferentes rutinas, etc.Si un programador cambia la rutina n. ° 1 y otra cambia la rutina n. ° 2, ambos devolverán file.ACD y alguien tendrá que combinarlos. – Bart

4

Una cosa simple que hacer sería hacer una diferencia de texto en los archivos .l5k para que pueda ver fácilmente si un desarrollador ha estado jugando con parte del archivo que está fuera de su alcance.

+0

Sí, eso es más o menos lo que estamos atrapados. – Dave

+0

@Dave: ¿En qué se diferencia este desarrollo de software general? Es posible que haya varios cambios por parte de diferentes desarrolladores; lo que necesita es un proceso típico de fusión de herramienta de administración de configuración en el que el último tipo que debe verificar debe fusionar sus cambios cuidadosamente. ... es posible que desee ver herramientas avanzadas de "diferencias", como nuestras herramientas http://www.semanticdesigns.com/Products/SmartDifferencer, que no es sensible al diseño. Tenemos los frontales L5K que se pueden usar con una herramienta de este tipo. –

+0

@Ira: en el desarrollo general, el código fuente se divide en muchos archivos pequeños en lugar de un único archivo monolítico. – Dave

5

Sobre RSLogix5000 específicamente, he visto a los desarrolladores usar un PLC emulado y hacer sus cambios en línea. El producto final una vez desarrollado se combina con todos los comentarios (ya que no están contenidos en el PLC) y luego se ponen en marcha. Hay problemas con los cambios que no se pueden hacer en línea, como AOI. Existen herramientas para evitar que dos personas editen la misma lógica en línea a la vez y se apropien de las secciones. Las copias de seguridad pueden realizarse en forma de cargas, pero no hay forma de seguir los cambios.

Es un problema complicado, aún más complicado cuando se está manteniendo un sistema como se desea .ACD con el que se puede conectar en línea, ya que a menos que se esté haciendo una diferencia con la herramienta de comparación RSLogix, se ve una máquina ilegible código como "+ | Éû³'¬ÙÆW × æ ™ μ,> Ù,"

El control de revisión más común que he visto (tristemente) es simplemente guardar el último archivo, luego tomar una copia y agregar la fecha actual al nombre del archivo, como la publicación recomendada de control.com descrita.

+0

Gracias por la respuesta. Este ya no es mi problema, pero definitivamente estoy interesado en posibles soluciones. He tenido este problema antes con PowerBuilder, y fue igual de feo. – Dave

6

Uso Unity Pro, por lo que es posible que esto no se aplique a otras marcas.

Unity puede exportar un archivo "de archivo" que es XML que describe el programa de PLC y la configuración de IO en su totalidad. Después de encargar los cambios, creo una exportación y la compruebo en mi repositorio local de Git. Esto me da un historial anotado de cambios, pero no una comparación visual. Siempre puedo usar UnityDiff para comparar.

Salida http://www.mdtsoft.com/ también

3

vi esta pregunta ahora desde un enlace en el intercambio de pila: Are There Realistic/Useful Solutions for Source Control for Ladder Logic Programs. En lugar de tener una respuesta de solo enlace, voy a engañar a mi respuesta aquí:

En realidad, hay una solución enlatada - de GE-IP de todos los lugares. Echa un vistazo a Proficy Change Management. Este producto controla la versión desde un punto de vista de sistemas de control PLC, en lugar de un control de versión pura del punto de vista de archivos; funciona como una capa situada encima de un VCS (la parte más aterradora es que originalmente este VCS era Visual SourceSafe) y maneja la administración de derechos, informes y pago/checkin.

Si bien el producto es de GE-IP, está diseñado para admitir una variedad de sistemas PLC y HMI listos para usar.

Divulgación completa, solía trabajar para una empresa que vende e instala PCM (pero eso fue hace 7 años). Entonces, si me preguntas cómo fue en ese entonces, ¡es probable que te diga dónde salió todo!

4

RSLogix5000 siempre ha prohibido la apertura y edición simultánea de múltiples usuarios en el mismo .ACD. Sin embargo, si varios usuarios tienen archivos .ACD idénticos, los abren y todos hacen conexiones con el mismo controlador de destino, cada uno de ellos puede editar en el controlador simultáneamente, pero solo si están trabajando en rutinas diferentes. Las ediciones de otros aparecen automáticamente, si fueran a mirar otra rutina de programadores.

Tenga en cuenta que el trabajo en línea como este se realiza generalmente con el PLC en ejecución, incluso a veces con el sistema de destino (algún tipo de máquina) en funcionamiento. Este tipo de arreglo con el propósito de completar el trabajo más rápido, o en algunos casos porque el sistema es enorme. Nadie se desarrolla así, ya que es una herramienta de depuración y poco práctica para cambios significativos.

Si un programador finaliza y otro no, el trabajo inacabado del otro se guardará en el .ACD del primer programador cuando guarden. Quien ahorre el último tendrá el trabajo de todos.

Al igual que otros han mencionado en este hilo, el uso de la fecha del archivo es bastante razonable. Algunas compañías usan una variable de control de versión que generalmente se muestra en una HMI conectada. Otras compañías usan un documento separado que documenta quién y qué cambia. A veces, las notas de la versión se colocan en un comentario de un renglón largo en la rutina principal.

Mi empresa utiliza un registro de cambios por separado y se mantienen copias de archivo fechadas. Los programadores múltiples solo se usan en los casos más extremos. Alguien siempre está designado para mantener la integridad del archivo sin conexión, generalmente la persona que trabajará más tiempo, o el administrador del proyecto.

Es importante tener en cuenta que los comentarios de escalón no se llevan de un usuario a otro antes de RSLogix5000 v21 porque las versiones anteriores no almacenaban comentarios en el controlador.

Dicho todo esto, es posible que esté intentando gestionar el desarrollo fuera de línea. No he visto ningún método sofisticado para esto. Por lo general, los programadores escriben las rutinas necesarias por separado, y un gerente de proyecto las ensamblará en un solo proyecto. El enfoque más limpio que he visto es donde un gerente de proyecto creará una arquitectura con funcionalidad global y asignará trabajo de rutina a otros, dándoles una copia de .ACD para trabajar. Devuelven el .ACD con cambios, y el administrador del proyecto copia y pega sus rutinas en el proyecto "maestro".

+0

Su último párrafo es lo que estábamos haciendo. Viniendo de un fondo de software convencional, esperaba más, pero como se muestra aquí (y confirmado por los desarrolladores de PLC en ese programa), es lo mejor que puede obtener. Además, bienvenido a StackOverflow. – Dave

5

Necesita un sistema de control de versiones especializado para PLC como VersionDog.

Desde el fabricante:

"apoyo especial con Smart Compara para SIMATIC S5, SIMATIC S7, SIMATIC PCS 7, WinCC, WinCC flexible, InTouch, CoDeSys, TwinCAT, Phoenix PC WORX, RSLogix, Schneider Modsoft, Schneider Concepto, Schneider Unidad, SINUMERIK 840D, Bosch IndraWorks y más. también robot programas de ABB y Kuka y formatos de datos relacionados con la oficina como Microsoft Word, Microsoft Excel y Adobe PDF son perfectamente compatibles por versiondog.

Actualización: Aquí hay una captura de pantalla que muestra ladder version compare. Supongo que eso es lo que les interesa a la mayoría de los PLC. También lo usamos para programar informes por correo electrónico si las versiones de las aplicaciones PLC en línea y fuera de línea coinciden, como una alarma de que algo ha cambiado en PLC pero no puesto en el servidor de control de versiones.