Download Control Engineering - Automation and Control

Group 1032i
13.2. RESULTS - USE CASE
• Define Communication Profile: As with the services, the communication hardware type can
be selected as modules by simple #define statements. The device drivers that have been implemented using this technique are Bluetooth USB, Bluetooth Serial, Power Line Communication
module and Ethernet drivers. The platform target definition is supported, however since the
development environments for the PIC processor and the Linux platform are very different, a
compiling to the PIC is not straightforward. The principle should work, but would be easier
using a target directly supported in the Linux environment.
• OHAP Conformance Test: Since the focus has been to create a proof of concept prototype,
the conformance test environment for an OHAP device has not been created.
A code base has been created from which modules can be inserted and removed as needed. Parts
of the code base has been ported to the PIC processor, but due to time constraints, this has not been
completed. The task proved to more difficult than anticipated because of the separation of memory
into banks on the PIC. It has four banks with 96 bytes each. The trouble is not the size of the memory
usage. Instead it is the fact that the compiler needs a reference to which memory bank a variable is
placed in. Pointers used as function parameters also needs to have the memory bank of the provided
pointer specified. Hence, all variables of the same struct type must be declared in the same bank
to be used in the same function. This proved to be tedious since these structs also had pointer to
other structs. It was decided to go ahead and implement more functionality in the PC setup instead
of continuing with the porting.
13.2.2
Technician
• Setup: The setup is made by the use of the automatic network configuration. In a final product,
more parameters depending on the device should be configurable.
• Remove Unit: A unit can be removed by either shutting the device down, or letting the router
send a SERVERRELEASE making the device leave the network.
• Service Check: The service check in the prototype is primarily based on status information on
the router and the attributes of the devices. A device can also be force to leave a subnet by the
ANCP server.
The current status is that a unit can be removed, reconnected, and the device explored for attributes
and services. Even though more functionality is needed in order to reassign devices to other subnets,
configure specific connections, the function of the technician can still be shown.
13.2.3
Daily User
The use cases that previously have been described will not be repeated here.
• Add Unit: As stated in the use case, a device which is in the proximity of the OHAP network
can receive an OP address. A device is always authorized per default, but this could be changed
so an acceptance must be provided before an OP address is delivered by the ANCP server.
169