Enterprise Architect Export – Student Assignment

Enterprise Architect Export – Student Assignment


In the Dezyne Modeling Language a user specifies logical behaviour of a system based on events and event driven behavior. Users can simulate the models to validate the specified behaviour. With the verification engine an automatic formal check can be performed on the model where a set of typical propoerties are verified. Finally code can be generated in a number of programming languages. Dezyne promotes a component based design approach where a system is based on components and interfaces. The behaviour of a component is often described by a state machine. To enable all these functions the modeling language of Dezyne is a formal language.

Create a function to export Enterprise Architect models

In developing new systems many designers want to start modeling in a less formal environment where they can work on the big picture first before having to pay attention to making an exact model. A popular environment is the tool Enterprise Architect (EA) where high level diagrams can be made in UML. Currently the models created in EA can only be transferred to Dezyne manually. The assignment is to create a function to export EA models in a format that can be read by Dezyne.

EA has a feature to export the models in an interchange format. This format must be parsed and converted into Dezyne files. Probably a lot of information in EA is not useful in Dezyne and must be filtered out. On the other hand probably also a lot of information is missing that is required in Dezyne. The approach should be to start with something relatively small and easy and gradually extend this in close contact with the Dezyne engineering team.

For this internship affinity is needed with

  • Model Driven technology and tools
  • Parsers

Interested?


[avia_codeblock_placeholder uid="0"]

Scenario Tool – Student Assignment

Scenario Tool – Student Assignment


In the Dezyne Modeling Language a user specifies logical behavior of a system based on events and event driven behavior. Users can simulate the models to validate the specified behaviour. With the verification engine an automatic formal check can be performed on the model where a set of typical errors are verified. Finally code can be generated in a number of programming languages. Dezyne promotes a component based design approach where a system is based on components and interfaces. The behaviour of a component is often described by a state machine.

In a given state the current simulator generates all possible next events. The user can select one of these events and the simulator continues execution of the model until it hits a decision point in another state. The decision point is again a choice between possible next events. After repeating this cycle a number of times a complete user scenario will have been completed. A scenario can be a “happy case”, i.e. the system behaves well and desired functionality is displayed. Alternatively, a scenario can be a case where the system hits some kind of fault condition and acts on that.

The challenge is to build a scenario tool that allows the user to ask questions like: “Is there a happy flow in the system” or “what happens if this fault occurs”? The user can drive the behavior of the tool by predefining selections on individual events, e.g. a sensor will always return ok or never return an error, so this limits the possible behavior as originally expressed in the behavior definition of components and interfaces. This is not intended as a full fledge verification engine where mathematical proofs for system questions need to be delivered. The possible user questions will be predefined and limited. Hence the possible user questions will not entail questions like “will the system never display this behavior”, or “will the system always respect this condition”.

The scenario tool will have to work closely together with the simulator to traverse through the state space and it is likely to be integrated with the simulator in the long run. Currently the simulator can only work on one component and its interfaces. For the new tool the same limitation will apply. It is the intention that the simulator will cover full system simulation in the near future and this does then also apply to the scenario tool as well.

Interested?


[avia_codeblock_placeholder uid="1"]

Lego Mindstorms – Student Assignment

Lego Mindstorms – Student Assignment


This vacancy is no longer available but other options will be available soon.


Verum uses a Lego Mindstorms model as a live demonstrator of results achieved with the Dezyne modeling tool. This is a model of a wafer stepper composed of a feeder robot, a 2d stage and a material handling robot. The control software is mainly written with Dezyne. It interfaces with the motors and sensors through a USB connection with four Mindstorms controller bricks.

The assignment is to extend this model to show new features in the Dezyne modeling language; for example dealing with multithreading. Together with a coach from Verum a new setup for the stepper control software will be defined that requires usage of these new features. One of the options is a distributed multi-processor design with controllers implemented on Raspberry-PI boards. Each of the sub-systems would have a dedicated controller and use an inter-process communication mechanism to interact with other sub-systems.

The total system must first be modeled in Dezyne and proven to be correct. After code generation the total system will be integrated in the Lego system and also have to work in practice.

Interested?


Send us an email