IL:initStatus

Introduction

Autoexport from the XML-Schema for element IL:initStatus of railML^® version 3.2 UML-visualization of IL
Documentation	The initial status of commands and messages on the interface in case of "cold start", i.e. a kind of predefined status to be assumed in absence of real information.
Subschema	interlocking
Parents^*	interface
Children	None
Attributes: comString: The status of all outputs as bit string starting with lowest bit. "0"-inactive, "1"-active, "x"-does not matter (obligatory; `xs:string`; minLength:1; patterns: [0-1x]), messString:* The status of all inputs as bit string starting with lowest bit. "0"-inactive, "1"-active, "x"-does not matter (obligatory; `xs:string`; minLength:1; patterns: [0-1x]*)
^*Notice: Elements may have different parent elements. As a consequence they may be used in different contexts. Please, consider this as well as a user of this wiki as when developing this documentation further. Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.

Autoexport from the XML-Schema for element IL:initStatus of railML^® version 3.1 UML-visualization of IL
Documentation	The initial status of commands and messages on the interface in case of "cold start", i.e. a kind of predefined status to be assumed in absence of real information.
Subschema	interlocking
Parents^*	interface
Children	None
Attributes: comString: The status of all outputs as bit string starting with lowest bit. "0"-inactive, "1"-active, "x"-does not matter (obligatory; `xs:string`; minLength:1; patterns: [0-1x]), messString:* The status of all inputs as bit string starting with lowest bit. "0"-inactive, "1"-active, "x"-does not matter (obligatory; `xs:string`; minLength:1; patterns: [0-1x]*)
^*Notice: Elements may have different parent elements. As a consequence they may be used in different contexts. Please, consider this as well as a user of this wiki as when developing this documentation further. Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.