Академический Документы
Профессиональный Документы
Культура Документы
estaciones remotas
OCIT O_Protokoll_V3.0_A01
OCIT ® es una marca comercial registrada de la compañía AVT Stoye, Siemens y Stührenberg SWARCO
OCIT estaciones remotas
Normas y protocolos
Contacto: www.ocit.org
derechos de autor • 2018 ODG. Sujeto a cambios. Los documentos con la versión o versiones de reciente reemplazan todos los
contenidos de las versiones anteriores.
3.5.1.1 dispositivos de campo con conexiones de datos permanentes en el panel de control ....... 15
especificaciones
la OCIT estaciones remotas configuración documento OCIT O KD V3.0 proporciona una visión general de todos
los derechos de autor gestionado por las especificaciones de la ODG y se encarga de versiones y lanzamientos
por:
• especificaciones de apareamiento la interfaz "estaciones remotas OCIT para los controladores de tráfico",
con referencia a las especificaciones OCIT-C que se acompañan,
• proporciona una visión general de paquetes de especificaciones para las interfaces, por su uso de
la ODG requiere una tarifa mínima es
El registro de documento OCIT-O contiene las definiciones en las estaciones remotas gama OCIT a seguir
para las interfaces compatibles de realización. El documento describe:
Una visión general del sistema de OCIT se encuentra en el sistema de documentos OCIT S. En este
documento, sólo el área OCIT estaciones remotas se trata. La zona marcada con OCIT estaciones remotas en
la Figura 1, al mismo tiempo representa el rango de definiciones, por lo tanto los límites del sistema OCIT
estaciones remotas son. Interfaces, que van más allá de los límites del sistema ilustrados no se definen en este
documento.
Un sistema OCITOutstations consiste en una unidad central (nivel central) y los dispositivos de campo
OCITOutstations. Sede y dispositivos de campo se comunican a través de las interfaces OCITOutstations.
La tarea típica de OCIT estaciones remotas es el funcionamiento seguro y seguimiento de los dispositivos
de campo a la distancia, con un reconocimiento inmediato, la respuesta y el tratamiento de errores se lleva
a cabo. conoce a partir de los protocolos TCP e IP de Internet se utiliza para la transmisión segura de
datos entre la sede y los equipos de campo. Por lo tanto, la velocidad de transmisión depende de las rutas
en la red y el volumen de datos. Los tiempos de transmisión, por lo tanto no se pueden predecir en cada
caso individual. Sin embargo, no se manifiestan al operador en general. Este tiempo se tiene en cuenta en
todas las especificaciones. OCIT estaciones remotas pueden ser utilizados como el rápido crecimiento de
oportunidades en la tecnología de las telecomunicaciones y de la red en la carretera y tiene una base
técnica para el futuro. Esto también hace que sea posible adaptar OCITOutstations con el tiempo para
cumplir con los nuevos requisitos y ampliar funcional, el volumen de la expansión no se conoce todavía. A
partir de esto, derivar una demanda: la ruta de transmisión no debe ser cargado con los datos críticos en
el tiempo, con el fin de evitar la congestión futuro en su enfoque.
Este requisito se cumple si las tareas de control de tiempo crítico llevan a cabo en los dispositivos a nivel
local y no pueden fijarse entre la sede y el dispositivo a través de la interfaz. Tales sistemas se denominan
"sistemas distribuidos". Por lo tanto, los dispositivos de campo OCIT estaciones remotas tienen
procesadores que manejan los complejos procesos a nivel local y realizan el procesamiento apropiado.
Los comandos y datos cuando ciertos eventos se muestran en la interfaz OCIT O. , acciones oportunas en
todo el sistema son controlados por tiempo
Los dispositivos de campo son controlados por un nivel central y monitoreados. El nivel central puede consistir
en varios componentes y subsistemas, que pueden estar ubicados en diferentes lugares. Una función definida
de la unidad de control de señal de luz también requiere una función correspondiente en la sede. Además,
estas unidades están equipadas con la llamada de acceso al sistema central. Herramientas de servicios
también pueden comunicarse desde el centro de control directamente a los dispositivos de campo. El acceso a
la herramienta de servicio a los dispositivos de campo cuasi paralelo a los accesos de la unidad central. La
función más importante es que en el sistema central de acceso permite el suministro a distancia de los
controladores de tráfico.
Para los intercambios, las siguientes propiedades son necesarias para comunicarse con OCIT O:
OCIT tiene su propia definición para el protocolo de transmisión del nivel de usuario que puede coexistir
con los estándares de Internet, el "protocolo de Capa básica paquete de transporte" (BTPPL). BTPPL fue
desarrollado en vista de las veces existentes en las redes urbanas conexiones de los cables de control con
potencia de transmisión reducida. Funciona con una pequeña sobrecarga de datos y por lo tanto hace que
sea posible el uso de estas rutas.
BTPPL proporciona dos canales para el transporte de datos. Un canal de alta prioridad puede ser utilizado para
la conmutación de los comandos y los mensajes en el canal de baja prioridad, los datos remotos pueden ser
suministrados, por ejemplo. La operación es asíncrona. Un remitente puede enviar continuamente nuevos
mensajes y no tiene que esperar a la reacción apropiada después del envío de los telegramas, pero puede
asignar este tiempo después de su llegada. Una parte integral del protocolo es el algoritmo SHA-1, lo que
asegura la protección de contraseña a través de una de 24 bytes, que la
BTPPL se puede comunicar a través de diversos medios de transmisión que utilizan TCP / IP. Existen normas y
dispositivos de comunicación, por lo tanto estándar para muchos de estos tipos de comunicación. Ejemplos: DSL,
Ethernet, pública digital de la red telefónica conmutada y operación de líneas arrendadas en redes privadas a través de
módems analógicos.
En el sistema de OCIT algunos de estos procedimientos estándar para la comunicación entre dispositivos de campo y los
paneles de control son adecuados. Las disposiciones correspondientes de OCITStandard se llaman perfiles de transferencia
OCIT. Consisten en declaraciones en relación con las funciones del sistema, tipo de medios de comunicación y equipos de
transmisión, requisitos mínimos de rendimiento de transmisión, las características de administración, entre otros
Con perfiles de transmisión OCIT diferentes controladores de tráfico de diferentes fabricantes pueden
funcionar sin ningún tipo de acuerdos adicionales.
"Perfil 1 - Perfil de transmisión para conexiones punto a punto sobre canales dedicados de comunicación". La
transferencia tiene lugar aquí CCITT con módems analógicos
V.34 con típicamente 28.800 bps.
"Perfil 3 - Ethernet con DHCP". Estandarizada es la conexión a Ethernet, una tecnología de red de datos
por cable para redes de datos locales que permiten un fácil acceso a diversas redes de comunicación es
posible.
No en perfiles de transmisión estandarizados OCIT se pueden implementar específico del fabricante, pero requieren
cambios de hardware y de software para controladores y paneles de control.
Los dispositivos de campo con interfaces OCIT O se llaman dispositivo maestro individual. El mando a
distancia es lógicamente siempre, incluso si esto es "el único centro" de varias partes o componentes del
sistema. que llega de las órdenes centrales, por tanto, siempre se llevan a cabo por los dispositivos de la
misma manera sin distinguir de qué componente del que proceden.
Debido a la sincronización del protocolo OCIT estaciones remotas, los dispositivos de campo se construyen
específicamente para su uso en sistemas de configuración distribuida. tareas de control de tiempo crítico se manejan en
estos sistemas a nivel local en los dispositivos de campo. Por lo tanto, los dispositivos de campo tienen procesadores
que manejan los complejos procesos a nivel local y realizan el procesamiento apropiado.
Diseñado específicamente para OCITOutstations, protocolo de ancho de banda optimizado BTPPL incluye
funciones de los niveles de usuario 5 a 7. Con la excepción de OCITOutstations Protocolo BTPPL sólo se
utilizan protocolos estándar.
TCP / UDP / IP son los protocolos de transporte de los niveles medios 3 y 4. Todos los comandos que son mayores que
4 KB, deben ser transmitidos a través de TCP. TCP es obligatoria para poner en práctica!
UDP y TCP, es posible que varias instalaciones de transmisión se pueden definir para los futuros
requisitos sin la parte principal de los cambios de protocolo. En principio, todos los servicios de medios y
de telecomunicaciones usuales pueden ser conectados a través de las capas 2 y la primera protocolos de
conexión se utilizan de acuerdo con el medio de transmisión a utilizar y el medio de transferencia. En
OCIT se establece el tipo de equipo de transmisión de documentos en el "perfil". ¿Qué interfaz, y que
conecte el fabricante utiliza para conectar estos dispositivos siguen siendo liberarlo.
Para su uso entre la sede y los equipos de campo principalmente de punto a punto de conexiones, por
tanto, se encienden las vías de transmisión dedicados en cuestión, en los semáforos propios tendidos de
cable de los clientes existentes. Por lo tanto, este perfil de transmisión se define como la primera (1 perfil
- perfil de transmisión para las conexiones punto-a-punto sobre vías de transmisión dedicados). Aquí el
protocolo PPP (Point-to-Point) y se utiliza como un dispositivo de transmisión
La copia de seguridad de transferencia se realiza en el plano de transporte, y dependiendo del protocolo en la capa 2 (capa de enlace
de datos).
Desde los centros a menudo están conectados a redes tales como Internet o Intranet, un número indeterminado de
usuarios puede tener acceso. Especialmente con las redes internas, muchos usuarios tienen legítimo El acceso. En
ambos casos, un ataque de "hackers" es posible. Por lo tanto, el control de los dispositivos de campo en el nivel de
usuario tiene dos etapas asegurado en OCIT estaciones remotas Protocolo
SHA-1 es una suma de comprobación de seguridad que detecta cualquier transferencia y los descartes no
autorizado. SHA-1 también se utiliza en otros contextos para formar firmas digitales y es reconocido como
un mundo seguro. Para la transmisión asegurar una contraseña separada se requiere ( OCIT O contraseña) la
prueba del interlocutor. La aplicación de este método tiene la ventaja, entre otras cosas que el acceso al
sistema no tiene que ser necesariamente una copia de seguridad por un firewall. El costo de este
procedimiento sostiene basa en el tiempo total de ejecución dentro de límites estrechos, ya que sólo una
muy pequeña parte de la comunicación se asegura de esta manera.
3.1.2 cortafuegos
El algoritmo SHA-1 protege el dispositivo de campo que ignora los comandos no seguras. Si Hacker las
interconexiones entre los dispositivos de campo y el centro eléctricamente
Los fabricantes de Centroamérica ofrecer sus dispositivos de comunicación centrales suelen tener una
protección más o menos elevado de estas intrusiones. redes administrativas son usualmente aseguradas
mediante el uso de servidores de seguridad en varios niveles del sistema.
3.2 direcciones
dispositivos de campo y el centro se comunican a través de direcciones IP. En una red de soporte y, por tanto,
cada dispositivo de campo debe tener una dirección IP única. Principalmente vienen direcciones de autogestión
en cuestión. El uso de direcciones reales pagados a Internet es posible, pero debido a la gran cantidad de
direcciones de Internet requeridos poco realistas. Esta "red de dispositivos de campo" a menudo será una red en
forma de estrella a través de líneas definidas por el usuario. Cada dispositivo tiene un nombre de host único
(véase el párr. 5.2).
3.3 red IP
Es un proyecto específico de determinar si OCIT estaciones remotas y las direcciones de los componentes
centrales se encuentran en una red IP común. Si es necesario, proyecto específico utilice un servidor de seguridad.
La comunicación directa entre los terminales centrales y los dispositivos de campo de ingeniería de tráfico
sobre la red IP se define sólo en el acceso al sistema central.
3.4 rutas
Debido al uso de IP en la capa OSI 3, es técnicamente posible, en principio, para llevar mensajes a "rutas", por
lo que las transmisiones de dispositivo de campo a dispositivo de campo o a otros componentes del sistema.
Con conexiones en forma de estrella mientras que las "rutas" a través del centro, que funciona de forma similar
a una central telefónica tiene lugar aquí. No se han tomado disposiciones para estas funciones.
3.5 Momento
El sistema no está diseñado para transmisiones con el tiempo determinista. La velocidad de transmisión alcanzable
en la red depende del sistema de comunicación y la carga de datos en la red. Por lo tanto, las acciones oportunas
en todo el sistema se llevan a cabo con control de tiempo. Para este propósito, se proporciona en el plano central
de un servicio de tiempo, relojes internos del dispositivo presentado después (en el caso estándar), de modo que
todo el sistema de tener todos los dispositivos en una base de tiempo uniforme. Todos los mensajes y comandos
están provistos de una "marca de tiempo", que se clasifica en el tiempo.
El sistema requiere un tiempo de sistema de concordancia en el panel de control y todos los dispositivos de campo
con una precisión de • 500 ms.
El Centro ofrece a la NTP servicio de tiempo Versión 4 (RFC 5905) que puede ser utilizado por los
dispositivos de control de luz de señal OCIT para sincronizar la hora del dispositivo al tiempo central.
Nota: Están conectados a un centro de control y dispositivo de campo con una versión más pequeña OCIT V3.0 (por
ejemplo, V2.0 o V1.1) conectado centro de servicio de tiempo también la NTP Versión 3 mosto (RCF 1305)
proporcionar o estar configurado de manera que las solicitudes de NTPv3 según la las definiciones de estas versiones
son contestadas.
El método de sincronización compensa los tiempos de transmisión en la red. El servicio de tiempo proporciona una
base de tiempo monótona que no conoce saltos por el horario de verano cambios de formato y sin zona horaria
(GMT). La hora UTC es la base de tiempo interna del sistema. Para la conversión de la información de ubicación,
hora local (zona horaria) y los puntos de cambio para el horario de verano / invierno son necesarios. Estos son
OCIT estaciones remotas que no están definidos se tradujo suministrada por los dispositivos OCIT en sus mensajes
UTC veces a la hora local se lleva a cabo en la sede.
Como un principio servidor NTP se aplica FNº. 0 (FG0) en la oficina central, donde la dirección IP se puede
obtener "búsqueda inversa". La configuración manual de NTPServern es una solución específica para el
proyecto.
Es especificada por el operador sin petición explícita, el servicio de hora central tiene la más alta prioridad en la
sincronización de la hora de la hora del dispositivo con la hora central. Relojes en los dispositivos de campo
forman la hora del dispositivo sólo después del encendido o cuando el servicio de hora central no está disponible
durante un tiempo predeterminado por el fabricante.
El servicio de hora NTP se encuentra en el centro de conexiones permanentes tales. B. OCIT O-perfil 1, al menos cada 15
minutos, y consulta inmediatamente después del establecimiento de la conexión.
Opcionalmente, el controlador puede estar configurado por el fabricante de manera que un reloj local forma la
referencia de tiempo priorizada para la unidad de tiempo. El servicio de hora central no o sólo entonces en caso
de fallo del reloj local utilizado. Con esta opción, la hora del sistema uniforme requerido sólo se garantiza si la
referencia de tiempo central para el servicio durante un tiempo pm similares how adquirido en los dispositivos de
control de señales de tráfico.
Una configuración con un servicio prioritario hora central no tiene sentido aquí como que se requieren
conexiones permanentes. Por lo tanto, los relojes locales se forman en los dispositivos de campo (DCF 77, u
otros sistemas), la referencia de tiempo priorizado para la unidad de tiempo. La hora del sistema uniforme
requerido sólo se garantiza si el
• cuando el estado de funcionamiento de los cambios de dispositivo (operación, mal funcionamiento, de error),
Los datos agregados y zwischengepufferte se transmite con una marca de tiempo. El sello de tiempo es
parte de los datos transmitidos.
En las transferencias no reconocidas un tiempo de espera debe ser proporcionada, teniendo en cuenta el tiempo de respuesta
máximo esperado.
El protocolo BTPPL utiliza un proceso de llamada asincrónica, que es el llamado programa avanza sin
esperar a la ejecución o un acuse de recibo de la orden. Por lo tanto, las respuestas a los comandos
pueden llegar a tiempo un orden diferente. El mapeo lógico entre comando y respuesta de la llamada
asincrónica - aseguró Responder mecanismo de protocolo BTPPL.
El comportamiento del sistema en caso de fallo del dispositivo de transmisión depende del tipo de dispositivo y sistema
de transmisión. especificaciones aplicables a todo el sistema que se encuentran en el documento "base". Definiciones
adicionales se pueden encontrar en los documentos de perfiles de transferencia.
En este capítulo, las capas OSI se describen 3 y 4. La Fig. capas OSI 1 y 2 se dan los perfiles en los
documentos OCIT-O.
Nota: Función se ha cambiado en comparación con la versión anterior (nuevo tamaño telegrama)!
Para la comunicación con los dispositivos BTPPL OCIT estaciones remotas de los paquetes TCP o UDP se utiliza en
función del tamaño. Todos los paquetes que son más pequeños de 4 Kbytes pueden ser transmitidos a través de TCP
o UDP; todos los paquetes de más de 4 kilobytes siempre deben ser transmitidos a través de TCP. Ya sea que se
transmite a través de TCP o UDP a través decide la sede. En una solicitud de TCP será respondida a través de TCP,
en una solicitud a través de UDP con UDP.
Suministro de objetos con btppl (como un mensaje con prioridad baja Ver también
5.1) de transferencia.
El tamaño del mensaje está limitado a 2 MB en TCP. El dispositivo de campo debe tener una
correspondientemente grande de memoria para almacenar temporalmente un suministro completo (buffer). Para
TCP btppl tamaños de telegramas para ser procesados por hasta 2 megabytes.
En una transmisión a través de UDP el número de trabajo (véase 5.1.1) y la dirección del puerto de
transmisión + IP del remitente almacenan enviados por el cliente de cualquier puerto de transmisión del
paquete y para asignar la respuesta. El uso de las garantías número de trabajo que pueden ser somete
desde un puerto transmisor de múltiples comandos, sin la necesidad de esperar a la respuesta de un
comando. En función de la importancia de la orden, el paquete se envía ya sea PNP o PHP.
El paquete es recibido por el servidor y se procesan allí. Para procesar el número de trabajo y la
dirección IP del remitente y el puerto original debe ser amortiguada con el fin de devolver la respuesta. Si
se produce la combinación de números mismo puerto serie / trabajo una vez más durante el proceso, le
corresponde a la puesta en práctica de ignorar este comando, ya sea o trabajar fuera una vez más. Una
vez que se procesa el comando, la respuesta es devuelta al número de trabajo original al puerto original.
cuando
Para enviar un paquete de telegramas una "Solicitud" de la respuesta se utiliza el paquete "Responder".
A medida que los paquetes sin realimentación, sólo se usan los "Mensajes" de abajo-definidos.
Antes de transmitir un paquete a través de TCP, se comprueba si un canal TCP ya está abierto. Si este no
es el caso, se abre un canal TCP. En función de la importancia de la orden, el paquete se envía ya sea
(puerto inferior priorizada) el PNP o PHP (Puerto de alta prioridad). El número de trabajo es transmitido
puesto que se requiere para los servidores y clientes de subprocesos múltiples. El canal permanece abierta,
al menos hasta que llegue la respuesta, o hasta que el tiempo de espera (fallo) se produce. pero tiene que
ser comprobada durante la ejecución de comandos si todavía existe el canal. En caso de fallo del comando
se aborta. El canal se abre de nuevo para el siguiente comando.
La respuesta es enviada de regreso al puerto que se originó la emisión. Durante el procesamiento del
canal permanece abierto. El servidor transmite el número de trabajo de la petición- en el
Respondtelegramm en TCP. Si el servidor no puede transmitir el mensaje de respuesta, se descarta y no
trata de abrir el canal nuevo.
En el puerto de transmisión de que el cliente espera de la respuesta (Respondtelegramm) en los anuncios enviados
comandos (mensaje de solicitud). Si (fallo) sin tiempo de espera después de una
seguridad en la transmisión de datos se produce contra la corrupción en el avión de transporte sólo para
TCP, UDP, pero no. TCP inicializa, monitores y termina la conexión y asegura que los mensajes llegan.
Este capítulo contiene la descripción de las estaciones remotas Protocolo OCIT y más con las definiciones
relacionadas con el protocolo tales. B. algoritmo de seguridad utilizado en OCITOutstations.
desarrollado específicamente para el protocolo OCIT estaciones remotas BTPPL. Esto vincula los objetos en los
sistemas remotos (dispositivos centrales y de campo) por llamadas a métodos. BTPPL hace que este método
llama a partir de telegramas a nivel / TCP / IP UDP. BTPPL utiliza estructuras de telegramas muy compactas.
BTPPL incluye:
excluye BTPPL
• los métodos de funcionamiento de las funciones del dispositivo (estos son la aplicación)
BTPPL es un protocolo simétrico. Se hace ninguna diferencia fundamental entre un dispositivo de campo y un
centro de control. Todas las unidades que participan son el cliente y el servidor. Por lo tanto, es por el
protocolo fácilmente posible que los dispositivos de campo pueden enviar comandos a otros dispositivos de
campo (tales como el nivel Central).
BTPPL utiliza la llamada. Método asíncrono llama. Aquí, por el protocolo de funciones se llaman (
"métodos") en un dispositivo conectado y ejecutados. Las necesidades de recursos de llamadas a
métodos asíncronos es significativamente más bajo que el método sincrónico llama. La funcionalidad
definible de la interfaz se puede dividir en, "propiedades" y "métodos" "tipo de objeto". La división ha
siguiendo de este modo de fondo: En todos los dispositivos hay una serie de elementos que son más o
menos independiente. En un controlador de señal de luz Son estos planes, por ejemplo, una señal cada
uno con sus propios comandos, puntos, diarios de operación o lógicas VA medición. Cada uno de estos
elementos, aunque no físicamente presente, en el sentido de la programación orientada a objetos, un tipo
particular de un objeto (tipo de objeto). Cada uno de estos objetos se puede abordar de forma individual y
tiene sus propias funciones (métodos), se centra en precisamente este
OCIT estaciones remotas requiere dos puertos por TCP y UDP: mensajes de baja prioridad se transmiten a
través de un puerto a través de los otros mensajes de prioridad de puerto. Ambos puertos se utilizan para
TCP y UDP. Durante la instalación de los dos puertos están predefinidos:
• mensajes de baja prioridad serán a el puerto 3110 transmitida. El puerto está en lo sucesivo
denominado PNP abreviada.
• mensajes de alta prioridad serán a el puerto 2504 transmitida. El puerto está en lo sucesivo denominado PHP
abreviada.
8 Contador de Tiempo de Trabajo Contador de Tiempo de Trabajo Miembro (Hola) Miembro (Lo)
Nota:
nombre significado
BL longitud de bloque. La longitud de bloque sólo se utiliza con TCP. Con UDP, se utiliza la
longitud de bloque del bloque de UDP.
HdrLen Longitud de la cabeza incl. Camino en bytes. Desde la dirección de HdrLen los parámetros
de comandos comienzan. Si no hay camino, HdrLen tiene el valor 16, de lo contrario 16+ < Longitud
de la ruta de entrada en bytes>.
OTYPE objeto
método Número del método dentro de la interfaz
ZNR número del centro. Cada panel de control de un operador debe tener un número
central único.
FNº Número del dispositivo de campo por debajo del centro. Todos los dispositivos que son
controlados desde un centro de control debe, central de lejos uno
tienen nombre único. El centro tiene siempre el campo de los dispositivos serie 0th
camino Objetos que existen más de una vez en un solo dispositivo están claramente definidos. La
longitud de los Pathtyps es diferente. Ellos se pueden derivar de HdrLen inmediatamente.
La ruta de acceso puede tener también una longitud impar.
bloque de Los parámetros de entrada en la solicitud y los bloques de mensaje, en el que los bloques
parámetros responden de la parámetros de salida. En los bloques de Respond, los dos primeros bytes son
siempre la palabra de estado en el que se ha registrado en el resultado de la función. El bloque de
parámetros tiene una longitud diferente. El bloque de parámetros puede tener una longitud impar.
UTC Hora en que se envió el paquete, como un formato sin signo de 32. El campo UTC
sólo se utiliza cuando un mensaje seguro es (es decir, con SHA-1) transmitida.
Cada dispositivo tiene un nombre de host único. El nombre de host se estructura de la siguiente manera:
El "ruebenstadt-sv.de" OCIT estaciones remotas LSA 5 en el centro 3 del operador por lo tanto tiene el nombre de
host:
fg5.z3.ruebenstadt-sv.de
En la oficina central, se establece un servidor DNS (Servidor de Nombres), y hay suministros específicos del
proyecto las direcciones IP de los dispositivos de campo. Los OCITOutstations El sistema accede (Nota:
OCIT O V2.0 no se ofrece) utilizaron para determinar la dirección IP del servidor DNS (RFC 1034, RFC
1035, RFC 974, RFC 1912).
La comunicación entre los dispositivos de campo a uno otro implica más de enrutamiento IP (todavía no estandarizados). La
asignación de direcciones IP se lleva a cabo para proyectos específicos.
Con esta opción, los cambios de nombres de dominio, el dominio de operador, que por lo general afectan a
todos los dispositivos controladores de tráfico / de campo de un área de control de forma automática. La
propietaria realizó Umversorgung los nombres de dominio de todos los dispositivos de campo en cuestión ya
no es necesario.
Los dispositivos de campo determinan a su nombre de dominio válido a partir de datos que se transmiten a los
dispositivos de campo durante la inicialización del nivel central. Estos datos se definen en los perfiles de transmisión
previamente establecidos. Por lo tanto, el dispositivo de campo recibe ya ha sido
Para determinar el nombre de dominio y la eventual modificación del nombre de dominio, el dispositivo de
campo, se ejecuta cada vez que se conecte una búsqueda inversa en DNS (DNS inversa) en la dirección IP y el
FG obtiene a partir de DNS a su nombre de dominio completo (totalmente cualificado nombre de dominio). Esto
está de acuerdo con el protocolo OCIT O:
Así, por ejemplo, fg5.z3.ruebenstadt-sv.de. Esta es la válida para el nombre de dominio del dispositivo de campo del
dominio de operador, en el ejemplo ruebenstadt-sv.de, derivada.
Cada nivel de componentes centrales OCIT S deben apoyar a la dirección del DNS de búsqueda inversa de
FG-IP.
• Los datos agregados se transmite en el momento (sello de tiempo) del inicio del intervalo. El
sello de tiempo no es parte de BTPPL pero el objeto respectivo.
Nota: Función se ha cambiado en comparación con la versión anterior (nueva regla de cálculo para el tiempo de espera)!
En las transferencias no reconocidas se debe proporcionar un tiempo de espera de la solicitud, teniendo en cuenta el
tiempo de respuesta máximo esperado. Para todas las transmisiones reconocido del mismo intervalo de tiempo:
longitud del telegrama = longitud de la solicitud + la longitud del telegrama Respond, cada uno de hasta e
incluyendo HdrLen Fletcher.
El tiempo de tiempo de espera se cuenta sólo desde el inicio de la transmisión (iniciar la entrega de la solicitud telegrama a
TCP). A la recepción de la longitud del telegrama responde, el contador de tiempo de espera ha de ser corregida
especialmente cuando largo mensajes de respuesta de acuerdo con la fórmula anterior.
Para los comandos un ID de proceso de 32 bits se puede definir, que es única en el sistema y se utiliza para el
funcionamiento de los diarios, etc .. El ID de proceso es una parte de los datos de un objeto. Se describe en el
documento base OCIT O. La especialización de las unidades de control de señal de luz se puede encontrar en el
O Esfuerzo documento OCIT.
Las respuestas a los comandos pueden llegar en un orden diferente en el tiempo. La asignación lógica se realiza
mediante la dirección IP, el puerto y el número de trabajo de 32 bits (el número de trabajo es parte del Protocolo
BTPPL).
Para la codificación de los datos en OCIT estaciones remotas un XDRFormat modificado se usa (RFC
1014). Para ahorrar ancho de banda siguientes cambios en el formato XDR se llevan a cabo:
• El tamaño del bloque básico (RFC 1014, punto 2) se reduce a 1 byte. El uso de 32 bits por byte es
demasiado grande. , 3.9 y 3.10, el valor de r (sin relleno) se establece en 0 3,8 - De acuerdo con
ello, en los puntos de RFC 1014a
• Además de la entero con signo (RFC 1014, sección 3.1) (16 bits) y un char firmado (8 bits) se
añadió a una-Short Firmado. En consecuencia, la
• Las cadenas son siempre con una longitud de palabra de 16 bits (USHORT) muestra que el número de
bytes (!) Indica en la cadena.
• Abhängig von der maximalen Zahl an Elementen wird entweder ein Längenbyte (max. 255
Elemente), ein Längenwort (65535 Elemente) oder ein ULONG vorangestellt, welches die Zahl von
Elementen angibt.
Die Union-Diskriminatoren (die nur sehr selten sind) bleiben bei jeweils 4 Byte Länge, um nicht
verschiedene Typen von Unions einführen zu müssen.
5.6 Objekte
Element Beschreibung
Objekttyp Todos los elementos que se puede acceder en un dispositivo de OCIT se asocian con un
tipo de objeto. Ejemplos de tales tipos de objetos son: plan de señal, detector, registro
(Member,
operativo, etc. Hay un número de tipos de objetos que son muy simples y sólo puede leer
OType)
o escribir acceder el ejemplo, tal como nombre del dispositivo.
OTYPE está el propio tipo de objeto. El número debe ser asignada de forma única para
los objetos estándar. En los objetos específicos del fabricante pueden ser definidos por el
fabricante, ya que los objetos sean distinguibles por los miembros.
Object ID
La mayoría de los tipos de objeto son redundantes. Esto se aplica por ejemplo a la señal
(ZNR, FNº,
Path) planes de 1 a n, detectores de 1 a n, archivos de mensajes de funcionamiento, etc. Para
distinguir la llamada. Instancias de estos objetos, se requiere ID de objeto, que es central
único a través de un operador. A diferencia de la mayoría de los sistemas de comunicación
en
OCIT estaciones remotas esta dirección (objeto ID) de longitud variable y,
todos "hablar". Esto significa que es posible a partir de la ID del objeto ya se dio lectura a los
datos pertinentes. El ID del objeto para un programa de señal, por ejemplo, consta de tres
elementos: número central (ZNR), número de dispositivo de campo (FNo) y el número de
programa de la señal almacenada en el Camino. Los tres elementos son para el usuario y lo
más importante para los programas de inmediato evaluados y "comprensible".
la camino no contiene ninguna o sólo un elemento en la mayoría de los casos. Sin embargo, es posible
que el camino también incluye una pluralidad de elementos, siempre y cuando la longitud total no exceda
de 240 bytes.
propiedad
La combinación de tipo de objeto y el ID de objeto se conoce como un objeto. Como se
desprende de las descripciones anteriores, hay por unidad de al menos un objeto (el
dispositivo real) y por lo general también otros objetos. Estas son algunas de las
estaciones remotas OCIT dictada, en parte definida por el fabricante.
método Todas las "funciones" que se ejecutan en un dispositivo OCIT, se refieren a objetos. Por lo
( método) tanto, ellos son tan comunes en la programación orientada a objetos como métodos se
hace referencia. Siempre es posible que los mismos métodos se pueden aplicar a
diferentes objetos. Métodos se agrupan en OCIT estaciones remotas siempre interfaces.
Todos los métodos son funciones con parámetros de entrada y salida y un resultado de la
función. El resultado de la función es un valor de 16 bits. Las primeras 10.000 entradas se
reservan para estaciones remotas OCIT. 0 significa que cuanto más "ejecución perfecta",
mientras que los valores de
1 ... 9999 son de error específico para estaciones remotas OCIT. Los valores superiores a 10000
están reservados para los fabricantes y tienen diferentes significados por el fabricante y por
propiedad.
Parámetros en el protocolo OCIT estaciones remotas es cualquier método con 0 ... n Eingangspa-
rametern parámetros de salida llamada y devuelve 0 ... n. cada
Cuando los mensajes (métodos sin parámetro de retorno de llamada) los beneficios del
programa sin esperar a la ejecución de la orden (llamada asincrónica).
Con la ayuda del número de miembro sistema de OCIT estaciones remotas para distinguir entre los objetos
y los objetos OCIT fabricante es posible. Miembro 0 y 1 son fijados por los objetos de la ODG OCIT
estaciones remotas. Cuentan con la norma. Los llamados objetos productores son creados de acuerdo con
las reglas OCIT propia responsabilidad de los derechos de autor. La gestión de los números de miembros
es responsabilidad del ODG. Usted lista actual está en el sitio web
www.ocit.org publicada.
Todos los objetos son identificados por un camino de acceso único a nivel mundial. Esta ruta de acceso se
compone de tres componentes sólidos y un "camino" longitud variable.
• La primera parte fija es el identificador de operador. Esto permite una comunicación transversal
central. Como portador de la identificación de una dirección de dominio real de Internet se puede
utilizar o una dirección de diseño similar una red aislada. Los operadores de dominio no es parte de
telegramas BTPPL, que sólo serán utilizados para construir las conexiones cruzadas clave.
Con estas primeras partes del nombre de host y la dirección IP puede ser determinado claramente que
tiene el dispositivo. Un dispositivo siempre se dirige sólo a través de una dirección IP.
La ruta se utiliza para identificar los objetos dentro del dispositivo. Por lo general, consiste en 0 o 1, más
raramente de dos o más entradas. Para los objetos que están presentes sólo una vez por dispositivo, el camino
está vacía. Los objetos tales como detectores, que pueden ser identificadas por una entrada tienen el número
como entrada Path. Sólo los objetos que están por debajo dichos objetos duplicados, tales como entradas de una
matriz, que se produce varias veces en la máquina, tienen más de una entrada (por ejemplo 3).
La falta de disponibilidad de una llamada desde el centro de control de esta función debe conducir a una reacción
perceptible del dispositivo de campo. Para el comando llamando desde el dispositivo de campo con un código de
retorno negativo es reconocido, mensajes explícitos OCITO el dispositivo de campo no se espera. Sobre la base
de los códigos de retorno negativos del panel de control puede generar mensajes o acciones (característica
opcional y específicos del fabricante implementa el panel de control) apropiados.
1. Se puede utilizar a pie en las RetCodes métodos, pero sólo se aplica si las condiciones acc.
Descripción.
2. Reunión de las condiciones no lo hacen, otros RetCodes apropiadas seleccionarse de acuerdo con la definición
contenida en el objeto XML RetCode 0:66 (OCIT O_Basis_vv.xml).
3. Si esto aplicar más RetCodes o parece ser adecuado, la selección se lleva a cabo de acuerdo con las
condiciones especificadas en la tabla de abajo prioridades. La prioridad de un valor RetCode tiene que
resolver la ambigüedad en la interfaz propósito OCIT S. Cumple con las condiciones para más valores
RETCODE, la RetCode debe ser enviado a la numéricamente mayor prioridad. La no un código de
colores en los RetCodes mesa ser generado por la aplicación y se envía sobre el alambre.
El verde marcada en las RetCodes tabla generada por el BTPPL-Lib y se envía sobre el alambre.
En caja en las RetCodes tabla generada por la instancia local BTPPL y no enviado sobre el alambre. Por
lo tanto, estos RetCodes tienen una prioridad más alta que los RetCodes la aplicación. los RetCodes
pueden producirse localmente con diferentes prioridades entre la aplicación y BTPPL-Lib.
3 SF_NOFOLLOW entregado segunda trama es correcta y no más tarde registrada segundo 1002
bastidores presente en la lista.
11 NOT_INACTIVE La lista no puede estar en ejecución para llevar a cabo este método. 1003
16 NOT_POSSIBLE si el tipo de orden permite que cualquier elemento de aplicación como sea 1006
posible con los mensajes, R09 y ICLD o cualquier otro trabajo o elementos de
trabajo más.
100 ERR_BAD_CALLCHK BTPPL: El método fue llamado con una suma de comprobación incorrecta. 2
105 ERR_FRAME BTPPL: encabezado no válido (longitud, banderas, suma de comprobación Fletcher) 13
200 ERR_SYNCHRONIZE BTPPL: generada después de la transmisión desde el transmisor cuando el tiempo del 6
bloque de retorno que está mal y el comando ya tenía un tiempo incorrecto desde el
cuarto bloque de transmisión. Este código no se utiliza entre la unidad de control y el
centro de control.
Es posible que durante el funcionamiento, se cambia la dirección IP del dispositivo de campo (pero no su
nombre de host!). BTPPL no debe hacer una consulta DNS para cada comando, porque esta consulta es
en recursos y tiempo. En cambio, los resultados de la consulta deben almacenarse en caché. Para
garantizar la coherencia de la memoria caché tiene que ser una invalidación de caché DNS en BTPPL.
Una vez que esto ocurre, las direcciones correspondientes deben ser redefinidas:
• en el arranque
• OCIT estaciones remotas telegramas están protegidos por diversas medidas contra la corrupción de
datos o ataques externos.
• La transferencia de la protección contra la corrupción de los datos y, por ejemplo paquetes UDP mal dirigidas o
ataques desde el exterior se efectúa mediante un algoritmo de Fletcher.
• Se requiere un aumento de la seguridad contra ataques desde el exterior para la transmisión de datos
relacionados con la seguridad y asegurado por un algoritmo SHA-1 (que calcula la suma de
comprobación de las palabras de paso y el contenido de datos).
Para la transmisión de fijación contraseñas son utilizados por los receptores respectivos para la
identificación o la verificación del remitente y el fusible transmisión SHA1 (véase la sección 5.7.3.) Puede
ser utilizado. La aplicación de este método tiene la ventaja de que el acceso al sistema y otros
compuestos no necesariamente tienen que ser asegurado a través de cortafuegos.
Los dispositivos de campo a saber por lo menos las siguientes contraseñas OCIT O:
• La contraseña del propio dispositivo (contraseña del dispositivo de campo, el centro de control o de otras
instalaciones)
Como se utiliza una contraseña, la contraseña del remitente en los mensajes de petición y telegramas
de telegramas Responder al remitente del mensaje de solicitud de contraseña correspondiente.
Dado que, por definición, un dispositivo central puede cambiar las contraseñas en los dispositivos de campo, es
necesario reproche allí para cada dispositivo de campo, los correspondientes pares de contraseña. Leer más en el
sistema de documento base OCIT O objeto de dispositivo remoto
Nota: Preferiblemente, todos los dispositivos de campo utilizarán la misma contraseña en el dispositivo de campo dentro de
un sistema centralizado.
• En el centro una OCIT O contraseña P1 se almacena. (Para cambiar las contraseñas una segunda
P2 entrada se crea en el centro, que está cubierto en el caso normal con el OCIT O contraseña P1).
La OCIT O contraseña P1 también está preajustado a la entrega de la unidad con
"OCITPASSWORT".
• El centro se realiza como el primer comando de cambio de la contraseña OCIT O estándar en el dispositivo de
la contraseña, que se utiliza en el centro de control (Procedimiento ver más abajo).
La contraseña OCIT O se cambia sólo desde el centro de control. El cambio se llevará a cabo de la siguiente
manera:
• La sede aceptado después de llamar solamente responde sólo con la nueva contraseña OCIT S.
Todos los mensajes restantes en la memoria caché de reintento son recodificados contraseña con la nueva OCIT O.
El algoritmo Fletcher es un algoritmo simple pero eficaz que requiere sólo 2 bytes por paquete. Él es un
algoritmo bastante desconocido, lo que hace que los ataques ad hoc:
initialize_fletcher void () {
c0 = c1 = 0; }
corto Fletcher () {
unsigned hi_fletcher Char = 255 - ((c0 + c1)% 255); unsigned char lo_fletcher = c1;
check_fletcher char () {
Para ejecutar el algoritmo debe ser llamado initialize_fletcher antes de la formación del byte de suma de
comprobación por cada atributo de datos a continuación do_check y finalmente forman con la suma de comprobación
Fletcher. Para verificar la suma de comprobación se realiza do_check Fletcher suma de comprobación de los datos
de atributos de bloque y (!) Y luego probó con check_fletcher si la suma de comprobación es correcta.
El algoritmo, por supuesto, se puede optimizar más. El ejemplo utiliza sólo las operaciones de 8 bits, y es
por tanto adecuado para portar en un controlador embebido.
Con lo anterior algoritmo Fletcher ser todos los telegramas OCIT estaciones remotas 'salvado'. Esto
asegura que muy pocos telegramas UDP perdidos al azar que se originan de software no OCIT, se
aceptarán como válidos los mensajes y confunden la acción. Además intentos de ataque por personal no
autorizado sean poco probable.
comunicaciones relacionadas con la seguridad, tales como nuevos suministros básicos o mensajes
operativos se asegura, además, mediante un algoritmo SHA-1 a los toques intencionales. SHA-1 es una
suma de comprobación que detecta cualquier transferencia y los descartes no autorizado. SHA-1 también
se utiliza en otros contextos para formar firmas digitales y es reconocido como un mundo seguro. El
algoritmo SHA-1 no se utiliza para el cifrado, pero sólo para el cálculo de la suma de comprobación
(algoritmos de cifrado requiere en muchos países un permiso de exportación por separado). La
probabilidad de un paquete falso es reconocido como correcto, es de menos de 10- 48a
(Documentación http://csrc.nist.gov/cryptval/shs.html )
otros:
• Según los conocimientos actuales, la posibilidad de diseñar a través del conocimiento de los paquetes
transmitidos previamente un paquete en comparación con la oportunidad de adivinar la contraseña
OCIT O insignificante.
• Se supone que no hay transferencia de datos fisgón seguida durante la fase de instalación del
dispositivo.
• La transmisión de datos real es en texto plano para facilitar la depuración, y de manera que no
choquen con las prohibiciones de criptología de ciertos países.
• La protección es una contraseña O OCIT que puede ser cambiado por el panel de control. Un
intruso que no es el viejo OCIT O conozca la contraseña no puede aprender la nueva contraseña
OCIT S.
Antes de que se forma la suma de comprobación, el campo UTC del bloque de datos BTPPL se llena con la hora actual
del sistema.
Para formar la suma de control del algoritmo SHA-1 se ejecuta utilizando la siguiente secuencia:
• OCIT O contraseña del remitente (sin byte de longitud, la codificación ISO8859-1) lleno con el
binario 0 a 512 bits. (El algoritmo comprime en incrementos de 512 bits, con lo que este primer
bloque de pre-calcula y almacena).
• BTPPL bloque de datos a partir de HdrLen (inclusive) a UTC (LSB) (ambos inclusive).
• la contraseña del OCIT O remitente (sin longitud de bytes, la codificación ISO8859-1). La suma de
comprobación así determinada se escribe en el campo de datos SHA-1 de la BTPPL bloque de datos.
Posteriormente, el algoritmo Fletcher partir de campo HdrLen sobre toda el bloque de datos BTPPL (offset 4
en TCP, UDP compensado 0) se realiza.
• Para cada comando que se almacena en el archivo Tipo OCIT estaciones remotas como relevante para la
seguridad, la suma de comprobación se genera con la OCIT O contraseña P1 y añade al final del conjunto de
parámetros.
• Si ambos valores son diferentes, el comando es rechazado con un error y dejó un mensaje al
centro de control.
• El receptor compara si el tiempo que se transmite en difiere de mando en más de ± 30 minutos del
reloj interno. Si el tiempo es diferente, el comando es rechazada con un error y también emitió un
mensaje al centro de control.
• The Central compara la suma de comprobación con la contraseña O OCIT para el dispositivo. esta
comparación falla, las votaciones se interpreta como falso.
• En respuesta a la hora incorrecta la hora local está incluido. Este caso no debería ocurrir
normalmente debido a que los dispositivos deben tener siempre la hora correcta. Para enviar en
tal caso, sigue contando, el cliente debe llamar a un GetTime sin garantía del objeto del sistema y
adaptar el comando en el momento equivocado.
Los siguientes códigos de retorno básicos son generados por el protocolo de seguridad / utilizado:
Para comprobar si el canal está todavía abierta, el cliente o el servidor puede enviar un mensaje de prueba a
través del canal TCP. El mensaje de prueba son simples ceros de 4 bytes en una fila. Desde BTPPL espera
que en este punto la longitud de un paquete siguiente (en este caso 0), el mensaje de prueba se puede
instalar fácilmente.
Una idea de la OCIT estaciones remotas para definir la interfaz en una forma formal, legible por
máquina. Sirve la siguiente meta:
Figura 4: Metamodel
BYTE signed char - 128 ... 127 transmitida como 1-byte (sin 8 bits con signo
alineación)
UBYTE unsigned char 0 ... 255 transmitida como 1-byte (sin 8 bits sin signo
alineación)
BREVE firmó corta - 32.768 ... 32.767 transferidos como 2 bytes, 16 bits con signo
Primer byte alto (sin alineación)
USHORT corto sin signo 0 ... 65.535 2 bytes transmitidos, byte alto 16 bits sin signo
primero (sin alineación)
LARGO firmado a largo - 2147483648 ... de 4 bytes transmitidos, byte alto De 32 bits con signo
2.147.483647 primero (sin alineación)
ULONG largo sin signo 0 ... 4294967295 transferidos como 4 bytes, 32 bits sin signo
Primer byte alto (sin alineación)
FLOAT flotador - 1E38 1E38 ... Codificación como codificación de número de coma flotante de 32 bits
dOBLE doble - 1E308 1E308 ... codificación como la codificación número de coma flotante de 64 bits
struct {STRING longitud de palabra de la siguiente campo (2 bytes) 1, cadena ANSI terminada en nulo (ISO
USHORT len, char 8859-1 [Latin-1]) caracteres de control son ignorados
str []}
BLOB struct {ULONG SZ, objeto grande binario, se transmiten en el opaco datos.
los datos byte []}
• DynAttribut
Los atributos dinámicos son heredados, que es una clase especializada también tiene todos los
atributos dinámicos de su clase base (s).
• STDMETHODS
Los métodos estándar no se heredan. Motivo: La firma del GET, la actualización depende de los
atributos dinámicos del dominio.
• métodos
son heredados, los números de método, sin embargo, son absolutamente indican que debe
tenerse en cuenta que debe ser mayor que MAXMETHODNR la clase base y menos de
MAXMETHODNR su clase es menor que el mayor número método estándar (15 =).
• camino
es con heredado. Si la clase base define un camino, la clase especializada tiene al menos el mismo
camino. Si el dominio de base ya está OBJTYPE, el dominio especializado debe ser un dominio
OBJTYPE. En la OCIT estaciones remotas tipo de ruta de archivo no es nueva dado.
El elemento de referencia se refiere a otro tipo (dominio) y pueden toda referencia tipos permisibles
dominio (NÚMERO DOMAIN STRING DOMAIN STRUCTDOMAIN, OBJTYPE etc.).
6.1.3 REFPATH
Si REFPATH se establece, en una referencia en la forma de un camino es (de ahí el nombre) transmitida
al objeto, que se especifica en el DECL. Por ejemplo, si se necesita una referencia a un nodo relativa en el
DECL se especifica y establecer REFPATH el objeto "nodo relativa". Dependiendo de la dirección
indicada por valor REFPATH (ver abajo) está así transferido, una cierta parte de la trayectoria del objeto
referenciado. REFPATH sólo se podrá establecer si los puntos de referencia a un dominio OBJTYPE (sólo
OBJTYPE dominios tienen una PATH).
• ZNR (2 bytes)
• FNº (2 bytes)
y luego es diferente dependiendo del tipo de objeto. En el caso del nodo relativa todavía sigue de cerca un byte
con el número de nodo relativa. El número de nodo relativa y el número de grupo de la señal: para grupos de
señales dos valores siguen. El camino es de este modo jerárquico.
Desde la primera parte de la ruta en la mayoría de los casos es redundante, se puede especificar cuando
REFPATH cuántos elementos se puede tomar del objeto contenedor y por lo tanto no se transmiten de
forma explícita. Por lo tanto, cuando se dirige un comando a un programa de la señal de un dispositivo de
cruce (el comando está incrustado en el telegrama BTPPL) una lista de AP-valores (que están incrustados
en el comando de programa de la señal), la referencia se divide como sigue:
• Cada valor único punto de acceso está dirigida únicamente por su nombre.
0: No suposición implícita de acciones de trayectoria, es decir, todos los elementos de la ruta del dominio de
operador objetivo ZNR, FNº y todas las demás acciones de trayectoria se transfieren.
1: dominio de operador se supone implícitamente. ZNR, FNº y el camino más del objeto
referenciado a ser transferidas.
Si REFPATH <0, esto significa: Sólo para referencia, los siguientes valores nletzten se transmiten. En -1, por
ejemplo, la referencia se establece sólo a través del último elemento trayectoria del objeto de destino en -2
por los dos últimos elementos de la ruta del objeto de destino, etc.
Si REFPATH no se establece, no de referencia es (por lo tanto sólo los datos como se muestra 6.1.2.)
Transferencia.
6.1.3.1 REFPATH_DATA
REFPATH_DATA transmite la ruta como REFPATH, pero también conduce a la final de la ruta de los
elementos de datos, por lo que los atributos dinámicos posiblemente existentes. La numeración es la
misma que REFPATH.
6.1.3.2 EXTENSIBLE
• Longitud de los datos transmitidos de la referencia (incl. Miembro / OTYPE) en bytes (rango 4 ...
255)
• Miembro (2 bytes)
• OTYPE (2 bytes)
• longitud datalen de siguientes datos en bytes como 2 o 4 bytes codificados (ver arriba).
• La información dada por los miembros, el tipo OTYPE (con dominio simple es la fecha del tipo en
sí, cuando StructDomain los atributos dinámicos existentes).
• Miembro (2 bytes)
• OTYPE (2 bytes)
• longitud datalen de siguientes datos en bytes como 2 o 4 bytes codificados (ver arriba).
• La información dada por los miembros, el tipo OTYPE (con dominio simple es la fecha del tipo en
sí, cuando StructDomain los atributos dinámicos existentes).
Los campos MINCOUNT y MAXCOUNT indican el número de elementos declaradas en la presente Decl.
Ambos campos son opcionales, si se han perdido MINCOUNT válida = MaxCount = 1, que es
exactamente uno de los especificados en el tipo de referencia. MaxCount siempre debe ser mayor que o
igual MINCOUNT.
Si se MaxCount MINCOUNT más grande, hay una matriz. En este caso, se puede anteponer el número
de elementos reales. Este número es un UBYTE si MaxCount-MINCOUNT <256, de lo contrario un
USHORT.
El MSGPART elemento meta es sólo un STRUCTDOMAIN especial, están predefinidos en los tres atributos
de clase: la categoría y formato de grados. Categoría incluye la categoría de mensaje como un número, el
MeldungsDegree grado que un número y formato a la cadena de formato.
Nota: La función se compara con la versión 1.1 se expande (formato de cadena de sumas de comprobación)!
Como parte de OCIT es posible extender el estándar para objetos y métodos específicos del fabricante.
Para exponer estas extensiones a otros fabricantes cuando se utilizan diferentes sistemas de los
fabricantes, estos objetos son para describir completamente como un archivo XML (<proveedor>
AddOns.xml). Aquí, el prescrito en OCIT nomenclatura estándar para ser utilizado. Esto es
particularmente relevante en los mensajes secundarios. Para que puedan ser analizados de forma
automática desde el centro a mostrar y procesar un texto claro y mostrar estos mensajes en la superficie
es posible, la presentación deberán respetarse exactamente. Sólo se presentó un breve texto
característico para el mensaje. Puede contener cualquier texto y valores adicionales del mensaje. Desde
un mensaje, pero por lo general tiene una pluralidad de parámetros de mensaje, que contienen valores
diferentes, el valor debe ser utilizado en formato de tiempo de ejecución en el texto. Para indicar qué valor
de un parámetro del mensaje que se utilizará, el nombre del parámetro entre el signo @ debe estar en el
formato de texto.
El nombre o identificador de los parámetros de los mensajes que se pueden utilizar en una cadena de formato
con @ ... @ debe cumplir con el consiguiente "ruta" con el valor que se mostrará, (en lo sucesivo, ValuePath). En
el caso más simple, la valuePath sólo la simple nombre del parámetro del mensaje. A menudo, sin embargo, se
abordará un valor sobre una pluralidad de referencias de objetos de modo que los resultados en un punto por
separado ValuePath. la valuePath se muestra por ejemplo en el código HTML de la documentación de la
herramienta Texto.
Después de la evaluación del formato de cadena de formato del texto se mostrará de la siguiente manera:
El valor es 4711
Después de la evaluación de la cadena de formato todos los valores de la matriz a continuación, se mostrarán:
Las sumas de comprobación generados (20 bytes) son para ser mostrado en aras de la facilidad de lectura en 10
grupos, cada uno de 4 caracteres hexadecimales. Ejemplo: CAFE 1234 ABCD5678-A1B2-C3D4-1A1D-1234 CAFE
ABBA
6.1.5 MÉTODO
Este elemento meta describe un método. Un método tiene un número único dentro de la interfaz o
OBJTYPES (y sus dominios de bases) en la que se encuentra.
Un método tiene parámetros de entrada y de salida que se declaran en el vehículo de entrada IN y OUT.
BTPPL transmite los parámetros de entrada con una petición de que el parámetro de salida con un
telegrama Respond.
Nota: En las versiones OCIT O 1.0 y 1.1 de la autenticación de manera no puede seleccionarse en todos los
métodos. Si el AUTH día que falta en la definición de los métodos, se le considera como AUTH = Ninguno.
6.1.6.1 MARCO
(Key se define para OBJTYPE, orden): especifica el marco orden que es escrito por este orden en un
segundo marco. Los días valor Devuelve la referencia a miembro / OTYPE uno de 0: 290 a abzuleiteten
Structdomain que describe el formato de trama. El dominio referenciado describe un marco completo
orden. El marco de orden se especifica con <# miembros>: <AuftragsFrame_Typname> (Ejemplo: 0:
MWAuftragFrameR09). Este atributo se puede utilizar para los pedidos para los que el formato de datos es
estático, como telegramas RBL.
6.1.6.2 FRAME_DATA
(Key se define para OBJTYPE, AE): especifica los datos de usuario a ser escritos por este elemento de
aplicación en el marco de orden. La etiqueta de valor especifica la referencia a miembro / OTYPE un
dominio que describe el formato de los datos en el marco nombre. Se hace referencia a un dominio simple,
el valor escalar se escribe en el AF. En una StructDomain sus atributos dinámicos en el AF se escriben.
(Ejemplo: 1: intervalo de tiempo). El atributo se puede utilizar para describir el formato de datos de las
órdenes en el que el formato de trama de orden resultante dinámicamente a partir de la asignación de
elementos de contrato a la orden. El atributo de clase se asocia así elementos de aplicación.
6.1.6.3 CATEGORÍA
(Key se define para MSGPART): Indica un mensaje a una sub-categoría, por ejemplo, hardware, sistema de
transmisión, el programa de usuario.
6.1.6.4 GRADO
6.1.6.5 FORMATO
(Clave se define para MSGPART): especifica un formato de texto para la presentación del mensaje. La
cadena de formato puede contener parámetros de un elemento de MSGPART definido dentro de las
etiquetas decl
Las definiciones de los datos utilizados en OCITOutstations dividen en objetos y objetos OCITOutstations
fabricante. Para se utiliza su descripción exacta de la norma XML, el (los fabricantes líderes de software
Microsoft,
el archivo OCIT O DTD_Vx.x.dtd describe la estructura de toda la usada en el dominio de la OCIT estaciones
remotas archivos de tipo. Véase también la sección. 6.2.3.
Los objetos OCIT estaciones remotas son descritos por los ficheros del tipo:
• el archivo OCIT O TYPE_Vx.x.xml dispositivo de campo contiene las definiciones para ciertos tipos de
dispositivos de campo.
Todos los tipos de archivos se estructuran de la siguiente manera. El día principal es OCT ( OC informática T IPO).
<! ELEMENT DECL (NOMBRE descripción, referencia, (MINCOUNT, MaxCount), (REFPATH |???? REFPATH_DATA), ampliable)>
<! ELEMENT STRUCTDOMAIN (NOMBRE DESCRIPCIÓN, MIEMBRO, OTYPE, Dominio de la Base?, * DECL los atributos de clase *)>
<! ELEMENT PATHPART (nombre, descripción, referencia, (REFPATH |?? REFPATH_DATA), ampliable)!>
<OCIT_TYPE_DATEI>
<OCTAVE>
El verdadero comienzo del archivo Tipo OCIT
<FABRICANTE> Semáforo Power Ltd. </ FABRICANTE>
Fabricante del dispositivo de unión. El fabricante en el ejemplo es ficticio, ya que todo el archivo de suministro.
si sólo los valores individuales tienen significado, es en lugar de INTDOMAIN un ENUMDOMAIN (ver abajo)
<BASE TIPO NOMBRE> USHORT </ BASE TIPO NOMBRE> <MAX> 999
</ MAX>
Valor máximo de la gama ENUM
Es posible que ciertas listas se utilizan repetidamente. Para ello existen
BASEENUMDOMAIN la entrada opcional que sería exactamente en este punto. La entrada contiene una referencia a un tipo anteriormente
declarado, que es también un ENUMDOMAIN. Cuando se establece una BASEENUMDOMAIN, todas las entradas se toman este ENUMS y
cualquier nuevos valores deben ser mayores que el valor MAX de BASEENUMDMAINS. Cuando existe un BASEENUMDOMAIN, incluso se
puede prescindir de MAX y otras entradas de entrada.
<ENUMENTRY>
Una entrada para la zona ENUM
<NOMBRE> Aceptar </ name>
Identificación de entrada
<Descripción> Método ejecutado con éxito </ description> <valor> 0 </ VALUE>
[...]
</ ENUMDOMAIN>
[...]
<STRUCTDOMAIN>
Además de los tipos de datos de dominio, hay tipos de datos de estructura que corresponden a los de struct conocidos o registros en PASCAL. Cada
elemento de una estructura es a continuación (véase más adelante) en un DECLFeld almacenado. dimensionales son posibles. matriz multidimensional se
da, ya que estos pueden ser declarado siempre como una matriz de una estructura que es una matriz de nuevo, y ser comprendidos este (un poco más
largo) definición tiene la ventaja cuando se trata de la estructura del telegrama.
Una referencia es una entrada especial que sólo puede referirse a las definiciones de dominio. Los anuncios son DOMINIO, NÚMERO DE
DOMINIO ENUMDOMAIN, CADENA DE DOMINIO STRUCTDOMAIN, OBJTYPE. Los siguientes campos indican que una definición de dominio
denominado ZEITSTEMPEL_UTC de Odgmember 0 (= ODG) es referenciada.
<Interface>
<Método>
Funcionalidad ofrecida por la interfaz. Hay en OCIT no hay procedimientos o funciones, únicos métodos. Un método es como asignado aquí una
interfaz, o directamente a un objeto.
Los parámetros de entrada y de salida se almacenan con SHA-1 suma de comprobación. Si no hay ninguna entrada,
los parámetros de entrada y de salida se guardan.
<OUT>
Gama de parámetros de salida. Los parámetros de entrada a la virtualmente mismo tipo definido (<IN>) y deben ser definidos antes de que los
parámetros de salida. Para los parámetros de entrada, la entrada ENUMDOMAIN faltante. Cuando el parámetro OUT no está presente, el método
no se responde con una petición / respuesta, pero con un mensaje. Puede por lo tanto, en métodos sin parámetros de salida no puede
garantizarse que la llamada se produjo a través de. Para ello, la llamada muy rápidamente (por ejemplo, para visualización de datos, etc.)
<DECL>
El primer parámetro OUT es el valor del resultado de la llamada al método. El tipo de datos hace referencia debe ser RetCode o
especialización de este. Este valor incluye se devuelven los errores de las capas de protocolo inferiores.
parámetros de salida adicionales son declarados por declaraciones Asev tales como elementos estructurales en el modelo.
</ DECL>
[...]
</ MÉTODO>
<METHOD>
<Nombre> GetElementeSeit </ NOMBRE>
<Descripción> elementos de tiempo Handed </ description> <NO> 3 </ NR>
<NOAUTHENTIFICATION />
Si esta entrada se establece, los parámetros de entrada y de retorno del método no se guardan con la suma de comprobación SHA-1. Si no hay
ninguna entrada, se almacenan los parámetros.
<IN>
Gama de parámetros de entrada. Los parámetros de entrada se definen en la virtualmente misma manera que los parámetros de salida
<DECL>
<NOMBRE> Tiempo </ name>
Tiempo para estar en qué elementos Lee <description> </ description> <referencia>
[...]
</ EN>
<OUT>
[...]
<DECL>
<Nombre> elementos </ NOMBRE>
<Description> Leer elementos. Puede diferente de
ARCHIV_ELEMENT derivarse tipos. </ Description>
<Referencia>
<Miembro> 0 </ member> <NOMBRE>
ARCHIV_ELEMENT </ name> </ REFERENCIA>
El tipo de objeto de que se declare OBJTYPE. Se compone de varios elementos: el tipo de la estructura de los datos se determina, que se puede leer con la
ayuda de Get y escrita por actualización. Obtener y actualización del sistema son métodos que no es necesario declarar una y otra vez, ya que están
codificados. Con interfaces nombre de la interfaz que se enumeran son apoyados por el objeto. Las interfaces ya están declarados anteriormente. En
STDMETHOD especifica qué funciones estándar (crear, eliminar, GET, Update) son compatibles. Finalmente, en el método se definen métodos, que se
aplican sólo a este tipo de objeto individual y para ningún otro tipo de objeto. El sistema tiene sólo acaba de patrimonio público. Si hay varios tipos de
objetos deben apoyar los mismos métodos, una interfaz debe ser declarada.
no hay entradas decl, es decir, no los propios datos (públicas). no hay atributos de clase
hay camino, es decir, por dispositivo de campo puede sólo una instancia con el miembro = 0, OTYPE entrar = 299a No hay STDMETHODS Si no
se define de datos separado, los métodos estándar no son útiles.
Los objetos que son varias veces en un dispositivo de campo se hace referencia claramente a través de un camino. Esta ruta se especifica aquí.
</ PATHPART>
<STDMETHOD> Obtener </ STDMETHOD>
Las variables del tipo de objeto se pueden leer, pero sólo todos juntos. Para poder editar las variables por separado, el objeto de otro tipo de objeto
debe ser el objeto .IF tipos se integran directamente, es posible leer todo el objeto, con un enlace a través referencia solamente la referencia
respectiva regresa.
<DECL>
<Nombre> ret </ NOMBRE>
<Description> Aceptar PARAM_INVALID, INTERVALL_INVALID </ description> <referencia>
[...]
</ PTU>
</ OCIT_TYPE_DATEI>
En los minutos dos áreas son fijos: la interfaz del sistema y el objeto del sistema. La interfaz del sistema
consta de los métodos de 0 ... 15, que incluye varias funciones para cada objeto.
El objeto del sistema es el objeto de la ODG 0 miembros. El subtipo es siempre 0. Sólo contiene las
funciones de programación y lectura de la contraseña OCIT S. Estas funciones no se combinan en una
sola interfaz, pero se muestran en la interfaz de 0 características especiales.
4..15 (Reservado)
6.3.1.1 Get
Get no recibe los parámetros de entrada y tiene (además del estado funcional) parámetro sólo una salida.
El parámetro de salida varía en función del tipo de objeto y es sólo la estructura que está en la lista
entradas Asev de DynAttribut (y todos los dominios de bases) de OBJTYP especificados.
2 Nota: Esta técnica hace que sea fácil de construir un navegador. Todos los objetos complejos que pueden ser tratados por separado, que se
refiere sólo referencias, de modo que para. Como cuando se lee un dispositivo de campo de información básica (nombre, no., ...) se transmiten
directamente, mientras que los elementos más complejos, como los programas de señal se almacenan como referencias y sólo se deben
mostrar su nombre. Sólo cuando el usuario selecciona ese elemento, el objeto se carga realmente.
6.3.1.2 actualización
Actualización establece el valor de un campo nuevo. Como una actualización de parámetros de entrada se pasa exactamente la
misma estructura que se ha proporcionado previamente con Get. También se pueden establecer referencias con esta función.
Una recolección de basura no tiene lugar, ya que los objetos pueden ser referenciados directamente en cualquier momento.
6.3.1.3 Crear
Los nuevos objetos se crean con "Crear". Crear obras como actualización. Los nuevos objetos se añaden desde el
dispositivo de unión de forma automática correcta. Crear recibe como entrada exactamente los mismos valores que
una actualización, simplemente no existía antes de que el objeto.
6.3.1.4 Eliminar
Con se eliminan Eliminar objetos. La función permite la eliminación sólo si no hay ningún objeto sobre el
tema se refiere. De lo contrario, una lista de objetos se devuelve que consiste en referencias a objetos
que todavía apuntan al candidato claro. salvará las referencias tan extensible REFPATH. El método
Delete se maneja con SHA-1 de autenticación
<BASE TIPO NOMBRE> ULONG </ BASE TIPO NOMBRE> <MIN> 1 </
MIN>
<MAX> 0xFFFFFFFF </ MAX> <NULLVAL>
0 </ NULLVAL> <Solución> 1 </ Solución>
<UNIT> segundo </ UNIT> </ NÚMERO
dominio> <NÚMERO dominio>
</ PATHPART>
<STDMETHOD> Obtener </ STDMETHOD>
<MAXMETHODNR> 32 </ MAXMETHODNR> </ OBJTYPE>
<OBJTYPE>
</ OCIT_TYPE_DATEI>
Nombre ObjC =
ObjC
name = ObjA1
0x38d0dea4 nr = 17
1 = ObjA2 objA tiempo =
0x38d0dfa9 nr = 23 name
ObjA tiempo =
3
ObjB tiempo =
0x38d0dfb9 nr = 37 name
= ObjA3 nombreB =
ObjB1
UDP
Método
OTYPE (Hola) 01 OTYPE (Lo) F4 Método (Lo) 00
8 (Hola) 00
UDP
RetCode 0 RetCode 0
16 38 D0
20 DF A9 17 06
UDP
Fletcher (Lo)
Fletcher (Hola) A8
16 A6
UDP
Método
OTYPE (Hola) 01 OTYPE (Lo) F6 Método (Lo) 00
8 (Hola) 00
ID.OTYPE (Lo)
ID.OTYPE (Hola) 01 ID.Path 00 Datalen (Hola) 00
28 F4
ID.OTYPE (Lo)
ID.OTYPE (Hola) 01 ID.Path 01 Datalen (Hola) 00
48 F4
Fletcher (Lo)
Fletcher (Hola) FB
92 BA
La detección del tráfico btppl-telegrama para propósitos de prueba se llama "rastreo". Hay dos
opciones:
El tráfico de mensajes se detecta en el dispositivo de control de la señal luminosa o en una instalación central y se
almacena en un "archivo de seguimiento". Esta capacidad de completar la detección del tráfico de telegramas btppl en
archivos de seguimiento es obligatorio para los dispositivos de la sede y de campo.
En los módulos OCIT O Biblioteca (src_btppl_type_040701.zip) para generar los archivos de seguimiento
(btppl_trace.c y btppl_trace.h) están incluidos.
Los archivos de rastreo se pueden leer con la herramienta de tipo O OCIT (typetool_WIN _.... exe,
typetool_LINUX _....). Tiene las siguientes características:
El tráfico de mensajes se detecta en línea por un dispositivo de detección externo (herramienta de seguimiento) sobre los
puertos designados (puertos de rastreo estándar) en la unidad de control de señales de luz o una instalación central y se
almacena.
• Detectar el tráfico de telegramas btppl a través del puerto de rastreo por omisión (línea de Búsquedas)
El principio de conexión rastro de servidor VD (Central) y el controlador de señales de tráfico para poner
en práctica.
Opcional cuando la estructura de toma de corriente, un criterio de filtro puede ZNR = xxxxx y / o FNR = xxxxx se
envía desde el instrumento de análisis, pero al menos uno LF (\ n).
Ejemplos:
tiempo de espera de socket: La herramienta de seguimiento debe de haber eliminado los datos dentro de 5
segundos de lo contrario la llamada se puede cerrar.
Nota: herramientas de seguimiento preferiblemente deberían estar conectados a través de sus propias
conexiones rápidas con el centro o la unidad de control de señal de luz, porque el volumen de datos se
duplica por el trazado en línea. Con uso simultáneo de la transmisión de perfiles 1 o 2 para control de
instrumentos y el rastreo de este modo los límites de la capacidad de transmisión se puede lograr.
Un archivo de rastreo btppl binaria consiste en una secuencia de registros de rastreo de la estructura se describe a
continuación. Todos los datos (es decir, primero MSB, LSB pasado) escritos en orden de bytes "btppl".
nombre
tipo observación
USEC OCIT_UI4 Microsegundo del segundo UTC cuando fue escrito registro
de rastreo.
protocolo OCIT_UI1 'U' para LoPrio udp, 't' para LoPrio tcp, 'U' para HiPrio udp, 'T'
para HiPrio tcp.
dirección OCIT_UI1 '>' Por telegrama recibido, '<' para el mensaje enviado.
telegrama HdrLen, banderas ... telegrama original, tal como se transmite, se inicia con la cabecera
Fletcher
btppl.
s. Cap. 5.1.1
OCIT_UI1 unsigned 0 ... 255 transmitida como 1-byte (sin 8 bits sin signo
char alineación)
OCIT_UI2 unsigned 0 ... 65.535 2 bytes transmitidos, byte alto primero (sin 16 bits sin signo
short alineación)
OCIT_UI4 unsigned 0 ... 4294967295 de 4 bytes transmitidos, byte alto primero (sin 32 bits sin signo
long alineación)
OCIT_SI1 signed char -128 ... 127 transmitida como 1-byte (sin 8 bits con signo
alineación)
OCIT_SI2 firmado corta -32.768 32.767 ... 2 bytes transmitidos, byte alto primero (sin 16 bits con signo
alineación)
OCIT_SI4 firmado a largo -2147483648 ... de 4 bytes transmitidos, byte alto primero (sin De 32 bits con signo
2.147.483647 alineación)
btppl_ip_address unsigned 0 ... 4294967295 de 4 bytes transmitidos, byte alto primero (sin 32 bits sin signo
long alineación)
btppl_port unsigned 0 ... 65.535 2 bytes transmitidos, byte alto primero (sin 16 bits sin signo
short alineación)
Para analizar los marcos de orden de los registros de seguimiento de, por ejemplo Liste.GetSFSince la
información en el momento de transferir la estructura de trabajo existente es necesario. Para ello, una entrada
de rastreo de la llamada al método GetListConfig () de SystemobjektFeldgeraet entró (petición y
responderemos) al principio de cada archivo de rastreo. El método no es explícitamente de una entidad externa
(por ejemplo, herramienta de seguimiento) se llama, se introduce, una estructura que tiene la información de la
orden en el archivo de seguimiento que corresponde a la devolución de la llamada GetListConfig (). Esta
llamada de método local no se transfiere a la sede o el controlador de señal de luz.
En la traza registros obtener el campo "IPADR" y "puerto" es 0, el "protocolo" tiene el valor 'x'.
En los parámetros de llamada ZnrFnrFilter deben ser introducidos para FNº y ZNR cada uno del valor cero
(65535) para la configuración de todos los dispositivos de campo se introduce.
Llame parámetros ListNrs (array vacío), de modo que se introduzca la configuración de todas las listas de
variables.
En la llamada parámetros ZnrFnrFilter la acumulación evaluado se deben introducir los criterios de filtrado de
conexión rastro. el valor cero (65535) se debe introducir para no incluido en los valores de criterio de filtro.
Para hacer que la configuración de la lista se introduce sólo para el equipo, para el que se transfieren
registros de rastreo.
Llame parámetros ListNrs (array vacío), de modo que se introduzca la configuración de todas las listas de
variables.
En el análisis de toma de esta información de la orden se envía una vez en la construcción de socket. La corriente
a través del puerto de traza y el archivo de rastreo son idénticos en contenido y se convierte en uno al otro.
Las explicaciones de los términos técnicos especializados y abreviaturas utilizadas en este documento,
consulte el documento "OCIT - O V3.0 Glosario".
Lista de Figuras
Figura 1: estaciones remotas OCIT - Interfaces .................................................. ....................... 8
Figura 2: Las capas en el modelo de referencia OSI ISO .................................................. .......... 12
Figura 3: protocolos para OCIT estaciones remotas .................................................. ........................ 19
Figura 4: Metamodel .................................................. .................................................. ..... 39