Release Notes
This version introduces the --gui-mock-devices flag which makes a collection of simple sensors and actuators available as virtual devices in the development gui. Note that --gui and --gui-mock-devices are mutually exclusive, only one should be enabled.
Calvin v1.1 enables the option of starting the development GUI together with the runtime using the --gui flag. (Still under development.)
The default is to serve the GUI on localhost, port 8000:
$ csruntime --host localhost --gui
See Calvin GUI for a tutorial on how to use the GUI.
Calvin v1.0 is now available on GitHub.
- Most of old calvinsys ported to new
- Updated and improved Raspberry Pi calvinsys
- Parser & compiler improvements (especially speed)
- Automatic (where applicable) handling of calvinsys states when migrating
- SQL-based registry available
- Csweb updated with new layout
- Scheduler refactored and made pluggable
- Cleanup & refactoring
- Additional tests
- and more
Calvin v0.8 is now available for download at https://www.github.com/EricssonResearch/calvin-base/
In this release, we have added support for a collection of sensors and actuators on Raspberry Pi, complete with a recommended pin configration, accompanying actors, and examples on how to use them. Further applications using these are forthcoming. See https://github.com/EricssonResearch/calvin-base/wiki/SensorKit. This is one of the larger milestones for this year.
In connection to the SensorKit, the graphical development environment now has support for graphical representation of some common sensors & actuators, making application development quite intutive. The possibility to try out Calvin in a sandboxed cloud environment will hopefully be enabled shortly. The IDE is available for testing on http://129.192.68.105/.
A majority of the old and new examples and associated devices have been checked to ensure they are still up to date, and where documentation was lacking, it has been improved. Of course, there are no guarantees that everything will work flawlessly - if discrepancies or problems are encountered, we welcome you to post an issue describing it.
In order to make it easier to implement new functionality and capabilities in the platform,, the old CalvinSys is being replaced. Under the new system, the capability system is quite a bit more flexible and is now somewhat similar to e.g. a linux device driver, and now follows a single function paradigm. At the same time, library functionality not related to hardware capabilities are handled similarly, but separate.
This is still a work in progress, thus parts of the old CalvinSys will remain in place during a transition period until all parts have been ported. The frameworks co-exist peacefully, but no new functionality will be added in the old framework. This is also a large milestone.
Tests have been partially reworked and are now using the same setup and teardown framework. As a result, the need for separate configuration of security tests have been eliminated and they are now enabled by default. This is part of the milestone enabling security by default.
Calvin v0.7 is now available at https://www.github.com/EricssonResearch/calvin-base.
There is now the option of having many-to-one ports (also known as fan-in ports) as well as the previously available one-to-many ports (fan-out). Additionally, it is now possible to add tags and/or an ordering to the connections.
This means that it is now possible to e.g. use an arbitrary number of incoming ports connecting to an actor, and, analogously, an arbitrary number destination ports. Still under development, first implementation available in a collection of "flow" actors
For example, the following
trigger: std.Trigger(data=true, tick=1.0)
therm1 : sensor.Temperature()
therm2 : sensor.Temperature()
cd : flow.CollectCompleteDict(mapping={"thermometer-1":&therm1.centigrade, "thermometer-2": &therm2.centigrade})
out : io.Print()
therm1.centigrade > cd.token
therm2.centigrade > cd.token
cd.dict > out.token
will collect the data from two temperature sensors (the CollectCompleteDict waits for all sensors to produce data; there is also a CollectDict which produces data as soon as some is available), and tag the data using the supplied mapping. The notation used in the mapping - e.g. &therm1.centigrade - is called a port reference. This is still a work in progress and there are still details to be worked out. See also Known issues below.
Internally, actors are implemented somewhat differently; among other things, guards can no longer look at the content of a token, only actions can do that. This was a rarely used option which had a major impact on performance (and predictability) of Calvin. It was also decided to cut down on the number of tokens an action could consume in one go to one per port (this was also a little used possibility.) Apart from reducing the complexity of the code, the resulting changes nets a rather neat performance improvement.
Deployment scripts have seen some work; there is now some experimental support for including deployment information in calvinscript.
Also somewhat experimental is the scaling and replication of actors. While superficially similar, the two are actually quite different when used. Replication is supposed to "cover" a collection of runtimes. For example, when deploying an application for collecting sensor values, it is possible to add a requirement stating that, e.g. "all temperature sensors in this building" should have a copy of a given actor. This is done at deployment and should only change if there is a change in the available sensors (runtimes.)
In contrast, scaling happens in response to a trigger of some kind; for example if a certain actor always has a full incoming queue, then this would be remedied by creating a copy of the actor on a different runtime, and then routing tokens there, aiming at keeping the queues of similar size.
Quite a lot of work has gone in to simplifying the development of applications. A key principle in the design of CalvinScript is to only add a new feature once we are certain it is needed. As of this release, there is now the possibility of referencing ports (as described above) and naming literals.
For example, the following is now possible:
log : io.Print()
save : std.SampleHold()
true > save.sample
:start "sample" > save.in
start.token > log.token
... etc ...
Internally, "sample" is an actor of type std.Constant, and once given a name can be used as any constant.
There have (of course) been a lot of work done on improving security as well. Among the many new features, we have secure runtime communication and the addition of secure http to the control API, both much needed improvements.
Although security is still switched off by default, we are approaching the point where at least the basic security features are easy enough to configure that they can (and will) be mandatory.
For those wishing to get a quick taste of how Calvin can speed up and simplify application development, there is now a proof-of-concept GUI available at http://94.246.117.105/.
The collection of examples has been extended to include usage of the new runtime extensions, including MQTT (Publish/Subscribe), OPCUA (Subscription), as well as a first shot at creating charts and graphs of data.
There is now a small (but growing) set of actors in the math namespace for performing simple math operations - compute and evaluate simple expressions.
The documentation has been, and will be, updated and reworked. This should make it easier to get started with Calvin, even for the less patient adopters.
As always, a lot of work has been done behind the scenes. There have been some performance improvements, both in theory and practice, and a lot of work has gone into making the runtime to runtime connections more robust & fault tolerance. The tests and the framework we use have been given an overhaul and should now be more robust and deterministic.
Port references does not currently work across component boundaries. A workaround until this is fixed is to insert an identity actor between a component port and then use the identity port in the reference. (See HTTPResponseTemplate in the webserver example for details.)
The focus of this release has been to rework some of the innards of Calvin in order to prepare for future extensions. Of course, it is inevitable that some new features sneak in, such as the new authentication framework (described in the wiki), or just plain improvements, such as the new keyword voidport in CalvinScript - a shortcut to mark a port as unused in a script.
The instructions for using Calvin in Dockers have been reworked and expanded. The creation of images have been simplified. See here.
Some documentation have been added to the examples, and the necessary requirements are included as an option in the installation script available here.
This version introduces a new flexible authentication framework for establishing the authenticity of the user that deploys and application, within a domain, the authentication procedure results in a set of user attributes associated with the instances of actors, the attributes are used as input for the authorization procedure. Similarly, a new flexible attribute based authorization framework is introduced. The framework is similar to XACML but designed to be more compact and efficient, it uses JSON and JSON Web Tokens for rules and transport. The certificate and key management has been substantially updated. Note: As for previous releases, all security features are disabled by default.
A lot of work has gone into restructuring and refactoring in preparation of the features planned for later this year. The parser and compiler has received a much needed overhaul in order to simplify extensions to CalvinScript, and the implementation of actor ports have been improved to allow for a more dynamic and configurable handling of tokens.
There are now a couple of examples of how to use Calvin with Dockers. It is still in an early phase, but if you are somewhat familiar with dockers, then a quick way of testing Calvin is to download an image and have a look.
There is now support for some new webservices, such as tweeting, and checking the forecast. There is also support for some new hardware.
There are a selection of new examples demonstrating how to use some features of Calvin's, such as using runtime attributes to store hardware configuration, such as which GPIO-pins are in use on a Raspberry Pi, and credentials, such as an API-key. Check the examples folder for details.
This version introduces signing of actors and applications, as well as verification of signatures, policy controlled runtime authorization for actors, and an option for using a secure DHT implementation for the internal registry. None of this is currently active by default.
If an actor is hogging the scheduler for longer than 200 ms, a warning will be issued in the log. There is a new extended trace functionality with detailed metering of actors events. CSWeb has been given a new look and supports the extended trace logging. Deployment of applications can specify and update actor requirements to guide the deployment on runtimes.
Location of configuration files can now be specified using a special CALVIN_CONFIG_PATH environmental variable. There have also been changes to the configuration of the internal registry - check this if you have issues with a previously working installation.
In addition to this, new tests have been added, as well as some refactoring for pythonicity.