Workflow - Production of operational FESA3 Equipment Software at GSI

---

Before you start to implement anything, you should clarify all requirements and ensure that all CS-CO-FE standards are fulfilled. This should be done by:

• Generate a first design draft, in consideration of the FESA Development Guideline
• Arrange a meeting with all necesarry people and present your design-draft. You will need the following participants:
  • Udo Krause or Ludwig Hechler (class functionalities, hardware connection, services and general design)
  • Jutta Fitzek or Raphael Müller (property names, middleware interface and class services)
  • Solveigh Matthies (or Alexander Schwinn) (FESA3 possibilities, class design, functionalities and code details)
  • The device expert (hardware connection and device specialities / behaviour)
  • The end user (interface and required services)
  • Yourself of course
• After all participants agreed on how the equipment software should look like, write an implementation proposal. This overview should contain information on the following issues:
  • Property - names and services
  • Realtime - actions and dependencies
  • Validation tests of the FESA class (ideally and if possible with the real device (hardware))
  • Any other FESA class-related information that could be relevant
• Send this proposal to all meeting participants (e.g. start on this wiki page: FESAclassDevelopmentSpecificEquipment) and wait for responses/change requests. If some fundamental points are still not agreed/fully understood, a second meeting could be necessarry.
• If everybody gave his/her ok, implementation may be started. You should begin implementation by using the GSIClassTemplate in order to follow the FESA Development Guideline and the recommondations on standard properties and value-items. If any trouble arises you can use the FESA3 wiki or directly ask the GSI FESA team for help (phone / email to the FESA support mailing list). We will support you on any problems regarding FESA3. Don't forget to provide a proper documentation for your class: inside the code using doxygen as well as in a separate document (e.g. Word, OpenOffice, LaTeX) or in the FESA3 way by providing an HTML page.
• Keep in mind that your first aim should be to implement a mockup class for testing purposes. This allows the application developers from CS-CO-AP to start GUI developments at an early stage (more details can be found in the FESA Development Guideline)
• You need to obtain a proper device name for your device which will be used for the device-instance names. For this purpose, please contact Maria Kuehn.
• As soon as you finished implementation, the GSI FESA team will review your code and help you test your implementation. If any problem is found during review/test, the FESA team will inform you about it. After you fixed the problem in your code, the whole process may be repeated, until the class is fully functional and ready for operation.
• You can install and run your class at an operational front-end. Please also note, that your class will be added to the operational source-code control repository. Per default you will be one of the persons in charge if changes for this class should be needed (FWK updates, ideas, wishes & user requests ...).
• If you have the feeling that an issue is missing on this list, please report it to the FESA team. We will check if we should add the missing task to this list.

When a FESA-class is operational and devices are to be installed, such that they should be accessed by operational applications, the devices should properly be made known to the directory server, and the access path should be checked explicitly. This also holds for mock devices.

• the instantiation file must be deployed by the FESA deploy button
• Access to the FESA devices must be checked by an appropriate test tool (a test tool from the CSCOAP-group is decribed here). It is noted that access by the FESA explorer does not assure that applications can access the device, because the FESA explorer uses a simplified access, mechanism.