Persistence as an option ¶ Some function blocks in the CODESYS Building Automation library contain data which may require persistence. |OperationalTime| .tOp could be a good example. Of course, some applications may not require those values to be persistent, but rather save the resources needed to handle persistence. In case persistence is required, the CODESYS Application Composer Module “Persistence Manager” can be used to provide this. For detailed information about the “Persistence Manager”, see https://help.codesys.com/webapp/ac_pm_overview;product=core_Application_Composer . Optional persistent aspects in the CODESYS Building Automation library carry the {attribute ‘ac_persist’} with a named “persistence group”. Right now, the CODESYS Building Automation library requires the application to use the “Persistence Manager” in a way to restore persistent aspects during initialization. To achieve this, set PersistenceManager.PersistenceChannel.xReadVarsDuringInit to TRUE. Currently, the following “persistence groups” exist in the CODESYS Building Automation library: BuildingLib_OperationalTime - operational time / counters of actuators, aggregates, etc.
MMAPS_FLAGS (ENUM) ¶ TYPE MMAPS_FLAGS : InOut: Name Initial MAP_SHARED 1 MAP_SHARED_VALIDATE 3 MAP_PRIVATE 2
MMAP_PROT (ENUM) ¶ TYPE MMAP_PROT : InOut: Name Initial PROT_EXEC 4 PROT_READ 1 PROT_WRITE 2 PROT_NONE 0
SEEK_MODE (ENUM) ¶ TYPE SEEK_MODE : InOut: Name Initial SEEK_SET 0 SEEK_CUR 1 SEEK_END 2
BuildingAutomation ¶ The Building Lib … Doc Aggregate variants CFC-specific considerations Example Air types - Terms, abbreviations, and colors Compile options Levels of application development and functional aspects covered currently Levels of application development covered currently Functional aspects covered currently Examples Functional aspects in the building automation field Implementation Implementation language Implementation rules Introduction Legal Disclaimer License Terms Levels of building automation application development Other useful resources OSCAT http://www.oscat.de/ OSCAT BUILDING LIBRARY - computation of physics. The following are especially worth mentioning: OSCAT BUILDING LIBRARY - blind modules: Persistence as an option System requirements and restrictions Exceptions System schemes Visualization Non-real-time testing and simulation - how to use the “warp clock” What is the “warp clock”? How to use the “warp clock”? Enums AutoOnOff (Enum) EnergyLevel (Enum) Error (Enum) HeatCoolOperationMode (Enum) ServiceIndication (Enum) Function Blocks Actuator Fan3Stage (FunctionBlock) Fan3StageState (Enum) HVAC_Coil (FunctionBlock) Functionality SetError (Method) HVAC_RotaryHeatExchanger (FunctionBlock) Functionality optional cleaning operation malfunction detection malfunction locking SetError (Method) HeatCool2Linear (FunctionBlock) IActuatorContinuous (Interface) DateTimeProvider (Property) Enable (Property) ErrorIdOut (Property) ErrorOut (Property) Reset (Property) Setpoint (Property) IActuatorOnOff (Interface) DateTimeProvider (Property) ErrorIdOut (Property) ErrorOut (Property) IsOn (Property) RequestOn (Property) Reset (Property) IValveContinuous (Interface) PumpOnOff (FunctionBlock) Application example Device examples Functionality on / off delay blocking protection command execution monitoring malfunction detection malfunction locking DateTimeProvider (Property) ErrorIdOut (Property) ErrorOut (Property) IsOn (Property) RequestOn (Property) Reset (Property) ValveContinuous (FunctionBlock) Functionality Blocking protection DateTimeProvider (Property) Enable (Property) ErrorIdOut (Property) ErrorOut (Property) Reset (Property) Setpoint (Property) ValveSixWay (FunctionBlock) Application example Device examples Functionality ValveThermo (FunctionBlock) Application example Device examples Functionality Normally closed valves and warmup: Blocking protection DateTimeProvider (Property) Enable (Property) ErrorIdOut (Property) ErrorOut (Property) Reset (Property) Setpoint (Property) ValveThermoWarmupState (Enum) WindowActuator (FunctionBlock) Application example Device examples Functionality WindowActuatorState (Enum) Aggregates Examples ExampleFancoil3StageAggregate (FunctionBlock) Fancoil3Stage (FunctionBlock) Functionality Control of fan speed dependent on valve position or control deviation FancoilContinuous (FunctionBlock) Application example Device examples Why does CODESYS Building Automation library contain a fan coil unit control strategy, even if some fan coil units come with integrated controller? Functionality Characteristic curve of fan speed Assemblies FourToTwoPipes (FunctionBlock) Application example Functionality Control CommandExecutionMonitoring (FunctionBlock) CommandVariable (FunctionBlock) HVAC_AntiFreezeControlMonitor (FunctionBlock) Application example Functionality HVAC_AntiFreezeControlSensor (FunctionBlock) Application example Functionality HVAC_AntiFreezeControlStartup (FunctionBlock) Application example Functionality RedundantPlantControl8 (FunctionBlock) SequenceControl (FB) Sequence combinations: Sequence relations: Control algorithm inputs: Relation between setpoints sequences: Other control characteristics: Integrator dynamics Reset “Anti windup” (integration limit) “Soft set” SequenceControlSequences (Enum) SequenceSwitch (FunctionBlock) Examples ExampleAirConditioning1 (FB) Air types Sequence control heater coil / cooler coil Hints Caveats ExampleAirConditioning2 (FB) Air types Sequence control damper / heater coil / cooler coil Recirculation air admixing and energy selection Minimum outdoor air ratio Water side anti-freeze for heater coil Air side anti-freeze Hints Caveats ExampleHeating (FunctionBlock) Heating circuit operation Night time setpoint reduction vs. switching off heating circuit operation Economy mode Optional anti-freeze Caveats ExampleHotWater (FunctionBlock) 2 point control of boiler temperature Legionella prevention Optional unload protection Caveats ExampleRoomAutomation (FB) Air types Presence controlled energy level Night cooling Energy lock Sommer compensation Fast heat / cool Window alarm Manual fan control Hints Caveats ExampleVariantsRoomControlFCUSimple (FunctionBlock) Examples_ImagePool (ImagePool) Misc DailyMeanTemperature (FunctionBlock) When does the daily mean temperature gets valid? “Warp clock”-enabled HeatingCharacteristicCurve (FunctionBlock) Application example Functionality HysteresisReal (FunctionBlock) LogBoolChange (FunctionBlock) RoomSetpoint (FunctionBlock) “effective comfort setpoint” Setpoint outputs - whats the difference Optimization EnergyLevelSetpoint (FunctionBlock) VDI 3814 reference HeatCoolUsingOutdoorAir (FB) Functionality Cooling mode Heating mode Time related DateTimeSplit (FunctionBlock) MaxOnTime (FunctionBlock) “Warp clock”-enabled MinOnOffTime (FunctionBlock) “Warp clock”-enabled OnOffDelay (FunctionBlock) “Warp clock”-enabled OperationalTime (FunctionBlock) “Warp clock”-enabled PeriodicTimer (FunctionBlock) “Warp clock”-enabled WarpClock (FunctionBlock) AddTime (Method) ComputeWarpFactor (Method) GetDateTime (Method) GetLocalSystemTime (Method) GetUtcSystemTime (Method) Functions LinTransf (Function) LinTransfClip (Function) LinTransfNormalized (Function) Log RealEquals (Function) RealGreaterEqual (Function) RealInRange (Function) RealLessEqual (Function) ServiceIndicationValue (Function) Time related DateTimeToString (Function) UdintInRange (Function)
Functional aspects in the building automation field ¶ Building automation can be subdivided into some functional areas. Even though such a subdivision is subjective, it may help to navigate in the CODESYS Building library. In the building automation field, we know at least the following functional system parts and areas: Primary plants (boiler plants, heat transfer stations, chillers etc.) HVAC (heating, ventilating, air conditioning) Room automation (controlling temperature, air qualitity, lighting, shading, and other aspects) Lighting control in general Optimization (of cost, energy consumptions, user comfort etc.) on specific levels of automation Building management Computer-aided facility management Building automation applications or libraries often come with support functionality or implementation for: Specific actuators Specific aggregates or assemblies Specific control or optimization algorithm
Implementation ¶ Implementation language ¶ There are two obvious implementation languages to choose from the CODESYS / IEC-61131 language set: ST and CFC. Implementations of functionality in level 1 and 2 is most likely to be done best in ST, while often implementations of functionality in level 3 is best done in ST. Computation of physics and simple algorithm might most obviously benefit from implementation in ST. There is an important design goal for the CODESYS Building Automation library: easy to understand and intuitive to use. In addition, the CODESYS Building Automation library is intended as a development template and not as a mature product. Therefore, understanding a function block and copying or modifying it to your own needs is essential. For this reason, it is most likely a good choice to select CFC as the implementation language from level 4 (possibly 3) to 6. Implementation rules ¶ There are some rules with which all functionality in the CODESYS Building Automation library should stick completetly: General implementation rules: The “Common Behaviour Model” should be used wherever appropriate (see https://help.codesys.com/webapp/idx-CommonBehaviourModel-lib;product=CommonBehaviourModel ). Function blocks related to time (axis) must provide an INPUT itfDateTimeProvider (Util.IDateTimeProvider) (see examples). In case the function block can fail somehow, there is an OUTPUT xError (error indication) and eErrorID (error ID). Both error indication and error ID will be reset by xEnable := FALSE or by xReset := TRUE (if it exists). In case of error situations, control outputs will be set to suitable values. Function blocks which implement an interface (for example, |ValveThermo| implementing |IValveContinuous| ) provide an output itf* (example: itfValveContinuous). This is about to support usability of the function block in CFC. More specific implementation rules for actuators and aggregates: Actuators and aggregates must provide an INPUT xEnable (BOOL) and work accordingly. Actuators and aggregates most likely provide the OUTPUTs xError and eErrorID. Actuators and aggregates sometimes work with “service indications” (quite often feedback values from the real hardware). “Service indications” INPUTs are implemented as a tuple of two BOOL, for example xSvciWhatEver : BOOL; xSvciWhatEver_Used : BOOL; // xSvciWhatEver_Used indicating if xSvciWhatEver is relevant, used, or connected. “Service indications” have a name prefix “Svci”. Actuators and aggregates sometimes work with “error indications” (error signals from the physical hardware). “Error indications” INPUTs are implemented as one BOOL, for example xErriWhatEver : BOOL; “Error indications” have a name prefix “Erri”. Actuator and aggregates which detect hardware errors (via “error indication” inputs or “command execution monitoring” utilizing “service indications”) optionally allow to hold the hardware error (“malfunction lock”) and shutdown the device (if appropriate) until error is reset
Introduction ¶ The CODESYS Building Automation library is intended to support the application development in the building automation field using CODESYS. It has the following characteristics: Developed by and within a community of contributors (including CODESYS GmbH having contributed functionality, acting as maintainer and taking care for releases) Provided with open source Free of charge The main design aspects or goals include the following: Easy to understand and intuitive to use Use “Common Behaviour Model” wherever appropriate Time (axis) related function blocks are “warp clock” enabled to support non-real-time testing and simulation. Oriented towards VDI 3814 Bl. 3.1 wherever appropriate The CODESYS Building Automation library is not intended to cover all aspects of building automation application development from the very beginning. It is intended to grow over time by contributions. To give users some additional support, the documentation of CODESYS Building Automation library will point to other open-source, free-of-charge libraries containing useful functionality not supported by the CODESYS Building Automation library. The CODESYS Building Automation library is intended as a development template and not as a mature product. The user is solely responsible for the tests in its application modules with the appropriate procedures and for verifying the necessary accuracy, quality, and functionality. Despite this, the CODESYS Building Automation library comes with extensive automatic testing. CODESYS GmbH will act as a maintainer of this library to ensure long-term compatibility and quality. At this point, we reference the license and the disclaimer mentioned in the documentation.
Legal ¶ Disclaimer ¶ TODO … License Terms ¶ TODO …
Levels of application development and functional aspects covered currently ¶ Levels of application development covered currently ¶ Unfortunately, there is not enough proper standardization in building automation application development - partially for good reason. Quite often, buildings (and their demand on building automation) are unique. System integrators have different levels of experience and use different procedures in planning and implementation of building automation. This altogether makes it rather impossible to provide a “complete” library which covers most aspects of the field. In general, it is more likely to provide useful functionality within such a library at levels 1 to 3. Aggregate manufacturers can improve building automation application development efficiency by providing functionality at levels 3 to 4 (possibly level 5) for their specific aggregates in their own libraries or contributing to CODESYS Building Automation library. Building application developers and aggregate manufacturers should be able to use elements provided by the CODESYS Building Automation library to improve their application development efficiency. Functional aspects covered currently ¶ The CODESYS Building Automation library starts with some: Specific actuators Specific aggregates or assemblies Specific control algorithms Specific optimization algorithms an example to demonstrate aggregate variants examples to demonstrate how to use the CODESYS Building Automation library in HVAC, primary plants and room automation To outline the design principles and provide the general infrastructure for implementation, documentation, release, etc. It is up to future contributions to extend and improve.
