1

I am going through the source code of the REDHAWK SDR framework and want to upgrade it to support SCA 4.1 specification. It already is partially compliant to SCA 2.2.2 version.

I have the IDL descriptions for the interfaces of the SCA 4.1 and compiled them with omniORB IDL compiler with C++ mapping. The skeleton and stub codes are generated properly. Now I want to understand how to do the following:

  1. where to place these generated skeleton and stub codes in the REDHAWK source code.

  2. Where to place the server and client codes based on these skeleton and stub codes in the redhawk source code

  3. I also want to upgrade to logging as specified in SCA 4.1 and available at link https://www.omg.org/spec/LtLOG/1.1/PDF. Here again I have generated the skeleton and stub codes but do not know how to proceed further.

  4. Am I missing something(or a lot).

Any pointers will be helpful.Please ask for any information I have not included as I am also in the learning stage.

Kaushal Kumar
  • 31
  • 6

2 Answers2

0

REDHAWK is an extension of SCA 2.2.2 rather than an implementation of it. Because of this, the IDL is not a complete one-to-one mapping of behavior, so even when switching the interfaces, you'll run into issues with mismatches in the underlying behavior. Also, REDHAWK extended the XML profile to include things like complex basic types and sequences as members of structures, which are not part of SCA 4.1.

You're also suggesting switching logging from log4cxx/log4j to the cos lightweight logging. Logging is embedded in the base classes of pretty much the entire code base and replacing it will be a substantial challenge

As a guide for the level of effort that you're considering, take a look at: https://github.com/Geontech/sca-jtnc. That project modified REDHAWK to implement the SCA 4.1 spec for the Python sandbox, code generators, a subset of device/component base classes, and a converter to transform REDHAWK projects into SCA 4.1 projects. It had to import multiple interfaces from REDHAWK and it does not include any of the system services (like the Domain Manager) or any updates to the IDE. That project can give you a working starting point to get you moving in the right direction and it should also provide you with some insight into the level of effort needed for the change.

Max Robert
  • 86
  • 2
  • "REDHAWK is an extension of SCA 2.2.2" --yes I agree with you on this point. REDHAWK implements SCA 2.2.2 with REDHAWK XML profiles, bulkio, burstio kind of additional features to enumerate a few. So in this sense it is definitely an extension. Keeping this in mind and having a look at the link provided by you " https://github.com/Geontech/sca-jtnc" -- this project is basically for device and component as per SCA 4.1 which can work in SANDBOX only and for redhawk project conversion from SCA 2.2.2 to SCA4.1 which can be a starting point. Anyways I am greatly indebted to you for your reply – Kaushal Kumar Aug 07 '19 at 10:42
0

It is fairly easy to write a very minimal implementation of CosLwLogService that supports just write_records, write_record. I chose to write one as a front end to log4cxx. This allows an application to make the standard CosLwLog calls and for the entries to print to the same log file used by the redhawk core framework (or redirected as log4cxx allows). I use log4cxx calls directly in my platform devices and services but this allows an SCA application to only use the standard CosLwLog calls. Of course, it is much more work to support the more complex features of CosLwLog but these are not as often needed by an SCA application.

Terry L Anderson
  • 263
  • 1
  • 11