Sandstar integrates Sandstar Engine, Haystack, and Sedona into a seamless whole
The device template is created in order to abstract system calls to GPIO, I2C, UART, and other hardware level communication. Within this file, we have utilized a tag called “channel”. Zinc in the form of a grid with records where “channel” tag which is type number is generated. Within the zinc file, we are forming all tags necessary to convert raw data into cur Val data form. This consists of tags that defines programming data type, port definition, sandstar engine, localization conversion, and last regular haystack tags are defined for application abstraction. Sandstar C/C++ engine consumes both files and communicates to both Sedona and Haystack rest API.
Abstraction in both hardware level and point definition level enables us to generate portable Sedona code. With the abstraction of IO, Sedona code can be written in a way it covers all potential input, output, and setpoint types. With the power of haystack ops (Rest API), we can add a record to the sandstar engine thus enabling the branch of the Sedona code that is waiting to be activated. We call this feature meta-morphing programming. On the roadmap, having haystack client in Sedona will help us to have P2P device communication along with historical data and analytics-based control.
Sandstar project will change how we think of DDC. Major improvements are hardware independent Sedona code, historical data based control logic, driver abstraction via haystack can be achieved now. With the improvements to haystack ops where Sedona components can be created changed deleted and linked, artificial intelligence can be utilized to generate and improve upon human-generated DDC code.