Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #1241

    cdknight
    Participant

    With all of the activity on SBN, I’m thinking it’s a good time to start a community sidebar. I will likely set up a weekly or bi-weekly discussion teleconference until we have some clarity on where we are and where we’re going in the next 6-12 months. For now, if you’d like to be part of that discussion, reply here and I’ll update folks once the holidays are over and I’m back to a regular work schedule.

    I’ve been actively enhancing and simplifying the SBN codebase and here are some thoughts from the workshop (but there may be other areas of development that I am not capturing below):

    * Merge SBN network modules with CI/TO modules?

    * More network modules (TTE, re-visit serial and spacewire, etc.)

    * Implement run-time reconfiguration (using same/similar command codes as TO) so new publishers and subscribers can join a network.

    * There’s a ticket to use the OSAL networking layer–for some networks they may have a PSP component rather than OSAL or a hybrid. Plus, as we add realtime, we might want to look at a common architecture for network devices, sensors, actuators, etc.

    * How (well) does SBN work in realtime environments?

    #1249

    markcpallone
    Participant

    I’ve been tasked with adding SBN to OCI FSW. I haven’t done much (well, anything) with it yet, but I’m interested in the app’s past and future.

    #1250

    cdknight
    Participant

    SBN has gone through many changes since “1.0”, I maintain a Powerpoint slide deck that may answer some of your questions about the current state and where it’s going. If you want, I can send the deck to you, if you can’t get to babelfish (the cFS GIT server.)

    Quick summary:

    • Back-end module architecture (TCP and UDP actively maintained, serial and SpacePort need updating, DTN prototype in the works.
    • Better network status protocol (which may change further as we evaluate/integrate TTE.)
    • Polling or multi-task concurrency.
    • Remapping and filtering of message ID’s.
    • Many bug fixes and rearchitecting to make the code cleaner.
    • Rich housekeeping.

    What may be in the future:

    • Returning QoS.
    • Removing protocol chatter for some backends.
    • Routing.
    • Addl. network backends.
    • Run-time reconfiguration.
    • Rich scheduling.
    #1251

    mbenson
    Participant

    When is v1.3 going to be released on Sourceforge? I see Sourceforge still has v1.0.0. I tried using v1.0.0 on a project a few months ago, but had to make too many code fixes to get it to compile. I ended up writing my own application which was similar to SBN.

    I had to bridge the CFE Software Bus to another framework entirely that had a similar concept as the CFE Software Bus, but was just implemented differently. I started adding functionality to SBN with the hope that I could eventually give it back. I added a sbn_custom.c file that included an SBN_CustomInit(), SBN_CustomSerialize(), and SBN_CustomDeserialize() functions. I also wrote a CFS library called PBLib (ProtoBuffer Lib) so I could exchange messages between architectures without worrying about ABI. I then wrote scripts to autogenerate the Serialize and Deserialize functions using my PBLib_Encode() and PBLib_Decode() functions. My SBN_CustomSerialize() and SBN_CustomSerialize() called the appropriate autogenerated function.

    #1254

    cdknight
    Participant

    If you’re a NASA employee or a contractor working on a NASA project, I believe I can get you access to our GIT. Otherwise, I will ask the CCB on Tuesday if I can send a copy directly to you. It should still be under the cFS license.

    FYI, the CCB is considering changing the way code is shared with external entities (like using github or somesuch.) This will make it easier to share in the future, but no decision have been made, as yet.

    #1257

    mbenson
    Participant

    I am a NASA contractor, but this particular project is not a NASA project. I would feel uncomfortable disseminating government created source code acquired via email.

    #1259

    markcpallone
    Participant

    SBN has gone through many changes since “1.0”….

    Thanks for the overview. I’m on babelfish, so I’ll add those slides to my todo list and stay tuned to future posts.

    #1670

    mitsu48
    Participant

    Is SpaceWire supported in SBN version 1.3?
    I am considering making SpaceWire available on SBN, but I think that the version 1.0.0 code has quite a lot of fixes.

    #1671

    cdknight
    Participant

    There was a back-end module in SBN 1.1 for SpaceWire but as SBN was upgraded, I did not upgrade this module. I am happy to re-introduce SpaceWire to SBN 1.3, but I do not have a test rig with SpaceWire to test. Drop me a direct line and we can coordinate development and testing.

    (Same thing applies to the Serial backend, which I may also bring up to the current version in parallel [no pun intended] to the SpaceWire upgrade.)

    #1672

    cdknight
    Participant

    On reviewing the SpaceWire module code, it sure seems like it is/should be identical to the Serial module (I have no experience with SpaceWire or how it is exposed by the OS to applications, but sure reads that it’s a character device read by standard OS file I/O calls.)

    (Also the SpaceWire module seems to have some fundamental bugs, including a loop problem addressed in later versions of SBN, but also a big file descriptor leak in GetData & SendData. Guessing this never got used. ;D )

    My direct e-mail address is Christopher.D.Knight@nasa.gov

    #1673

    mitsu48
    Participant

    Thank you for your reply.
    I will e-mail directly. but if SBM v1.1 have implemented a serial module too, I would like to know basic policy such as whether socket interface in sbnapp.c is only IP version communication.

Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.