Hardware Abstraction Layer For Robotic Technology Avatar
  1. OMG Specification

Hardware Abstraction Layer For Robotic Technology — Open Issues

  • Acronym: HAL4RT
  • Issues Count: 35
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
HAL4RT-23 device_kind is same as Device Kind ID? HAL4RT 1.0b1 open
HAL4RT-21 Is Profile ID same as Device Kind ID? HAL4RT 1.0b1 open
HAL4RT-10 There is no mechanism included for managing the ID for devices. HAL4RT 1.0b1 open
HAL4RT-8 Many of the definitions in the document are tautologies. HAL4RT 1.0b1 open
HAL4RT-30 More condition for Conformance HAL4RT 1.0b1 open
HAL4RT-29 UML-to-C Transformation HAL4RT 1.0b1 open
HAL4RT-25 Init() function must have some arguments including device ID but no argument in the specification HAL4RT 1.0b1 open
HAL4RT-24 Binding mechanism for callback functions to devices are not clear HAL4RT 1.0b1 open
HAL4RT-31 The definition of interfaces of Surface Layer HAL4RT 1.0b1 open
HAL4RT-35 Direction Sensor HAL4RT 1.0b1 open
HAL4RT-34 Attributes for GPS Sensor HAL4RT 1.0b1 open
HAL4RT-33 More attributes for robotic system are needed. HAL4RT 1.0b1 open
HAL4RT-38 The definition for Device Kind ID Registry is poor. HAL4RT 1.0b1 open
HAL4RT-37 Why does SetSpeed have tmAcc? HAL4RT 1.0b1 open
HAL4RT-36 Why the word, "torque" is used for motor? Not "force". HAL4RT 1.0b1 open
HAL4RT-32 2 typos in the table of Motor Operation HAL4RT 1.0b1 open
HAL4RT-20 Unnecessary use of RTC Octet type HAL4RT 1.0b1 open
HAL4RT-22 Functions arguments are empty in Surface layer header HAL4RT 1.0b1 open
HAL4RT-19 Incorrect integer types used in C PSM HAL4RT 1.0b1 open
HAL4RT-18 Date is a Real with range from 2015.0 to 2020.0. HAL4RT 1.0b1 open
HAL4RT-17 Is the word “exited” intended instead? HAL4RT 1.0b1 open
HAL4RT-16 What is meant by Octet [RTC]? Some of the attributes are typed by this. HAL4RT 1.0b1 open
HAL4RT-15 Clarify the sentence. HAL4RT 1.0b1 open
HAL4RT-14 device_kind is a string. HAL4RT 1.0b1 open
HAL4RT-13 If the return codes are an enum, why are they typed as a string and not as the enum or a short or int? HAL4RT 1.0b1 open
HAL4RT-12 Syntax errors in HAL4RT_Surface.h (robotics/15-11-04) HAL4RT 1.0b1 open
HAL4RT-11 The reason that the Surface layer is not necessary. HAL4RT 1.0b1 open
HAL4RT-9 Syntax errors in HAL4RT_Device.h (robotics/15-11-05) HAL4RT 1.0b1 open
HAL4RT-7 Inconsistent definition of notify_error(), and return value of "notify_error()" seems not necessary HAL4RT 1.0b1 open
HAL4RT-6 Inconsistent definition of notify_event(), and return value of "notify_event" seems not necessary HAL4RT 1.0b1 open
HAL4RT-5 Notation variability of terms: Application Program(ming) Interface HAL4RT 1.0b1 open
HAL4RT-4 "HAL4RT components" first appeared without any description in the section 7.4.1 HAL4RT 1.0b1 open
HAL4RT-3 Generic error code such as HAL_ERROR is not necessary? HAL4RT 1.0b1 open
HAL4RT-2 Difference between HAL_NULL_PARAMETER and HAL_BAD_PARAMETER is ambiguous HAL4RT 1.0b1 open
HAL4RT-1 Return Code HAL_NO_CONNECTED should be NOT_CONNECTED or NO_CONNECTION HAL4RT 1.0b1 open

Issues Descriptions

device_kind is same as Device Kind ID?

  • Key: HAL4RT-23
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    From Dr. Mizukawa,

    device_kind(Table 7.8: Device) is same as Device Kind ID?

  • Reported: HAL4RT 1.0b1 — Tue, 15 Mar 2016 17:32 GMT
  • Updated: Thu, 12 Apr 2018 14:59 GMT

Is Profile ID same as Device Kind ID?

  • Key: HAL4RT-21
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    From Dr. Mizukawa,

    7.4.5.1 HAL Component
    profileId
    A Profile ID identifies the kind of the device.

    Is Profile ID same as Device Kind ID?

  • Reported: HAL4RT 1.0b1 — Tue, 15 Mar 2016 17:26 GMT
  • Updated: Thu, 12 Apr 2018 14:59 GMT

There is no mechanism included for managing the ID for devices.

  • Key: HAL4RT-10
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    From Matthew Hause,

    It concerns me that there is no mechanism included for managing the ID for devices. Without this mechanism, it will be difficult for the implementation to succeed. The specification should at least describe how this is planned to be accomplished.

  • Reported: HAL4RT 1.0b1 — Mon, 14 Mar 2016 18:25 GMT
  • Updated: Thu, 12 Apr 2018 14:59 GMT

Many of the definitions in the document are tautologies.

  • Key: HAL4RT-8
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    From Matthew Hause,

    Many of the definitions in the document are tautologies. In other words, the definition of the element simply repeats the name of the element. I will not list all of them, but this is the case for most definitions. For example:
    “7.4.5.14 Direction Sensor
    Direction Sensor is a sensor to measure direction.”
    In some cases this is unavoidable, but in other cases the terms may not be easily understandable. This needs to be fixed in the document.

  • Reported: HAL4RT 1.0b1 — Mon, 14 Mar 2016 18:21 GMT
  • Updated: Thu, 12 Apr 2018 14:59 GMT

More condition for Conformance

  • Key: HAL4RT-30
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    More condition for conformance is needed.

  • Reported: HAL4RT 1.0b1 — Tue, 21 Jun 2016 15:20 GMT
  • Updated: Thu, 12 Apr 2018 14:59 GMT

UML-to-C Transformation

  • Key: HAL4RT-29
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    More definition for UML-to-C Transformation needed to explain mapping between PIM(7.4) and C PSM(7.5.2).

  • Reported: HAL4RT 1.0b1 — Mon, 20 Jun 2016 18:07 GMT
  • Updated: Thu, 12 Apr 2018 14:59 GMT

Init() function must have some arguments including device ID but no argument in the specification

  • Key: HAL4RT-25
  • Status: open  
  • Source: AIST ( Dr. Noriaki Ando)
  • Summary:

    Init() function must have some arguments including device ID but no argument in the specification.
    And also Init() function must returns device (HAL component's) handle or device descriptor.

  • Reported: HAL4RT 1.0b1 — Tue, 15 Mar 2016 18:44 GMT
  • Updated: Thu, 12 Apr 2018 14:59 GMT

Binding mechanism for callback functions to devices are not clear

  • Key: HAL4RT-24
  • Status: open  
  • Source: AIST ( Dr. Noriaki Ando)
  • Summary:

    completed(), notify_error() and some other callback functions exist in the specification. These callback functions must be bound to device layer or more deeper layer device entity. However binding mechanism and its related functions are not described in the specification.

    Callback functions binding mechanism should be provided and described.

  • Reported: HAL4RT 1.0b1 — Tue, 15 Mar 2016 18:24 GMT
  • Updated: Thu, 12 Apr 2018 14:59 GMT

The definition of interfaces of Surface Layer

  • Key: HAL4RT-31
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    In the definition of interfaces of Surface Layer, that are implemented on Surface App, both a set of methods for Application Base and another set of methods for Device Layer are defined in a same interface.
    For example, in the definition of System Interface, ‘get_error_detail()’ should be exposed only to Application Base, on the other hand, ’notify_error()’ should be exposed only to Device Layer.
    Those methods should be defined in two different interfaces to avoid inappropriate exposure.

  • Reported: HAL4RT 1.0b1 — Mon, 8 Aug 2016 04:18 GMT
  • Updated: Thu, 12 Apr 2018 14:59 GMT

Direction Sensor

  • Key: HAL4RT-35
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    It isn't a sensor.

  • Reported: HAL4RT 1.0b1 — Sat, 13 Aug 2016 00:50 GMT
  • Updated: Thu, 12 Apr 2018 14:59 GMT

Attributes for GPS Sensor

  • Key: HAL4RT-34
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    Unclear about DOP, Signal Strength etc.

  • Reported: HAL4RT 1.0b1 — Sat, 13 Aug 2016 00:48 GMT
  • Updated: Thu, 12 Apr 2018 14:59 GMT

More attributes for robotic system are needed.

  • Key: HAL4RT-33
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    In Device layer, there are few attributes for robotic system.

  • Reported: HAL4RT 1.0b1 — Sat, 13 Aug 2016 00:10 GMT
  • Updated: Thu, 12 Apr 2018 14:59 GMT

The definition for Device Kind ID Registry is poor.

  • Key: HAL4RT-38
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    The definition for Device Kind ID Registry is poor.

  • Reported: HAL4RT 1.0b1 — Mon, 15 Aug 2016 05:56 GMT
  • Updated: Thu, 12 Apr 2018 14:59 GMT

Why does SetSpeed have tmAcc?

  • Key: HAL4RT-37
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    Why does the operation, "SetSpeed" have the argument, tmAcc (Acceleration/Deceleration time to the target speed)?

  • Reported: HAL4RT 1.0b1 — Mon, 15 Aug 2016 05:54 GMT
  • Updated: Thu, 12 Apr 2018 14:59 GMT

Why the word, "torque" is used for motor? Not "force".

  • Key: HAL4RT-36
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    About attributes for Motor, why the word, "torque" is used for motor? Not "force".

  • Reported: HAL4RT 1.0b1 — Mon, 15 Aug 2016 05:49 GMT
  • Updated: Thu, 12 Apr 2018 14:59 GMT

2 typos in the table of Motor Operation

  • Key: HAL4RT-32
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    There are 2 typos.

    incorrect : Set the current position as origin
    correct : Set the offset position as origin

    incorrect : The target position
    correct : The offset position

  • Reported: HAL4RT 1.0b1 — Fri, 12 Aug 2016 01:27 GMT
  • Updated: Mon, 6 Nov 2017 12:34 GMT

Unnecessary use of RTC Octet type

  • Key: HAL4RT-20
  • Status: open  
  • Source: AIST ( Geoffrey Biggs)
  • Summary:

    In places in the specification the Octet type from the RTC specification is used. For example, in 7.4.5.1 "HAL Component". Additionally, this type is then mapped by 7.5.1.1.2 to a 32-bit signed integer, which is not what is implied by the name "octet" (i.e. a byte). Instead of pulling in the RTC specification for an octet type that is not used correctly, a "byte" should be specified, which is then mapped to uint8_t in the C PSM.

  • Reported: HAL4RT 1.0b1 — Mon, 14 Mar 2016 19:09 GMT
  • Updated: Mon, 6 Nov 2017 12:34 GMT

Functions arguments are empty in Surface layer header

  • Key: HAL4RT-22
  • Status: open  
  • Source: AIST ( Dr. Noriaki Ando)
  • Summary:

    dtc-16-01-01 section 7.5.2 C PSM and robotics/15-11-04 are a header of HAL's surface layer.
    Most of functions declared in there have no arguments.

    For example completed() function is declared in the header as follows,

    int32_t completed();
    

    However, in the Table 7.5 section 7.4.3.1 in page 21, completed() function is defined as follows.

    ReturnCode completed(string command_id, ReturnCode status);
    
  • Reported: HAL4RT 1.0b1 — Tue, 15 Mar 2016 17:29 GMT
  • Updated: Mon, 6 Nov 2017 12:34 GMT

Incorrect integer types used in C PSM

  • Key: HAL4RT-19
  • Status: open  
  • Source: AIST ( Geoffrey Biggs)
  • Summary:

    The C PSM given in 7.5.2 uses int32_t and uint32_t. Unless there is a specific requirement for these values to be 32 bits, they should be specified as "int" and "unsigned int" and it be left up to the compiler for the platform in use to choose appropriate sizes.

  • Reported: HAL4RT 1.0b1 — Mon, 14 Mar 2016 19:03 GMT
  • Updated: Mon, 6 Nov 2017 12:34 GMT

Date is a Real with range from 2015.0 to 2020.0.

  • Key: HAL4RT-18
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    From Matthew Hause,

    7.4.5.14 Direction Sensor
    Date is a Real with range from 2015.0 to 2020.0. The date needs to extend past 2020 or the specification will quickly become obsolete.

  • Reported: HAL4RT 1.0b1 — Mon, 14 Mar 2016 18:47 GMT
  • Updated: Mon, 6 Nov 2017 12:34 GMT

Is the word “exited” intended instead?

  • Key: HAL4RT-17
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    From Matthew Hause,

    Figure 7.10 – State Machine of Motor
    The details of each state are below.
    ・Wait(Not Excited):
    Is the word “exited” intended instead?

  • Reported: HAL4RT 1.0b1 — Mon, 14 Mar 2016 18:45 GMT
  • Updated: Mon, 6 Nov 2017 12:34 GMT

What is meant by Octet [RTC]? Some of the attributes are typed by this.

  • Key: HAL4RT-16
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    From Matthew Hause,

    7.4.5.1 HAL Component
    What is meant by Octet [RTC]? Some of the attributes are typed by this.

  • Reported: HAL4RT 1.0b1 — Mon, 14 Mar 2016 18:44 GMT
  • Updated: Mon, 6 Nov 2017 12:34 GMT

Clarify the sentence.

  • Key: HAL4RT-15
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    From Matthew Hause,

    Section 7.4.5
    “If the nature of the product, an API that does not function exists, it will implement all of the API.”
    Please clarify this sentence as it is confusing.
    Same for “(A motor which is corresponding to only the speed control in, or if it can not support the torque control API · Position Control API) And, non-support API will be implemented as you plan to return the "API unimplemented error (HAL_NOT_IMPLEMENTED)" as the API of the return value.”

  • Reported: HAL4RT 1.0b1 — Mon, 14 Mar 2016 18:42 GMT
  • Updated: Mon, 6 Nov 2017 12:34 GMT

device_kind is a string.

  • Key: HAL4RT-14
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    From Matthew Hause,

    Section 7.4.4 Table 7.8: Device
    The kind of the device. For examples, Motor, Encoder, Gyro sensor, Acceleration sensor, Force sensor, Torque sensor, Temperature sensor, Humidity sensor, GPS sensor, Direction sensor etc.
    device_kind is a string. Does this mean that you will be using character matching to find the name of the device? Would it be better to use an enum or other type of construct?

  • Reported: HAL4RT 1.0b1 — Mon, 14 Mar 2016 18:39 GMT
  • Updated: Mon, 6 Nov 2017 12:34 GMT

If the return codes are an enum, why are they typed as a string and not as the enum or a short or int?

  • Key: HAL4RT-13
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    From Matthew hause,

    If the return codes are an enum, why are they typed as a string and not as the enum or a short or int?

  • Reported: HAL4RT 1.0b1 — Mon, 14 Mar 2016 18:36 GMT
  • Updated: Mon, 6 Nov 2017 12:34 GMT

Syntax errors in HAL4RT_Surface.h (robotics/15-11-04)

  • Key: HAL4RT-12
  • Status: open  
  • Source: AIST ( Dr. Noriaki Ando)
  • Summary:

    Since HAL4RT_Surface.h (robotics/15-11-04) includes some syntax errors, it cannot be compiled.
    1. To use int32_t #include <stdint.h> directive necessary. (C99)
    2. Invalid function pointers declarations in SENSOR structure.
    3. Invalid #endif syntax.

    At least the following modifications are necessary.

    HAL4RT_Surface.h.patch
    --- org/HAL4RT_Surface.h        2016-03-15 03:11:51.496000000 +0900
    +++ mod/HAL4RT_Surface.h        2016-03-15 03:27:33.664000000 +0900
    @@ -1,6 +1,7 @@
     #ifndef HAL4RT_SURFACE_H
     #define HAL4RT_SURFACE_H
    
    +#include <stdint.h>
    
     int32_t completed();
     int32_t notify_event();
    @@ -14,30 +15,30 @@
    
    
     typedef struct ApplicationBase {
    -  int32_t completed();
    -  int32_t notify_event();
    -  int32_t notify_error();
    +  int32_t (*completed)();
    +  int32_t (*notify_event)();
    +  int32_t (*notify_error)();
     } APPLICATIONBASE;
    
    
     typedef struct System {
    -  int32_t notify_error();
    -  int32_t get_error_detail();
    +  int32_t (*notify_error)();
    +  int32_t (*get_error_detail)();
     } SYSTEM;
    
    
     typedef struct Command {
    -  int32_t execute();
    -  int32_t completed();
    +  int32_t (*execute)();
    +  int32_t (*completed)();
     } COMMAND;
    
    
     typedef struct Event {
    -  int32_t subscribe();
    -  int32_t unsubscribe();
    -  int32_t notify_event();
    -  int32_t get_event_data();
    +  int32_t (*subscribe)();
    +  int32_t (*unsubscribe)();
    +  int32_t (*notify_event)();
    +  int32_t (*get_event_data)();
     } EVENT;
    
    
    -#endif HAL4RT_SURFACE_H
    +#endif /* HAL4RT_SURFACE_H */
    
  • Reported: HAL4RT 1.0b1 — Mon, 14 Mar 2016 18:30 GMT
  • Updated: Mon, 6 Nov 2017 12:34 GMT

The reason that the Surface layer is not necessary.

  • Key: HAL4RT-11
  • Status: open  
  • Source: Japan Embedded Systems ( Kenichi Nakamura)
  • Summary:

    From Matthew Hause,

    Section 7.4.1
    [OPTIONAL] In addition, the Surface layer is not required because HAL4RT aims “light and compact” specification.”
    I am not sure what this statement means. It seems to say that the Surface layer is not necessary. However, the previous text is all about describing why it is necessary. Please explain.

  • Reported: HAL4RT 1.0b1 — Mon, 14 Mar 2016 18:30 GMT
  • Updated: Mon, 6 Nov 2017 12:34 GMT

Syntax errors in HAL4RT_Device.h (robotics/15-11-05)

  • Key: HAL4RT-9
  • Status: open  
  • Source: AIST ( Dr. Noriaki Ando)
  • Summary:

    Since HAL4RT_Device.h (robotics/15-11-05) includes some syntax errors, it cannot be compiled.

    1. To use int32_t #include <stdint.h> directive necessary. (C99)
    2.Syntax errors without sentence termination character ";" in ACTUATOR and SENSOR structure declarations.
    3. Invalid function pointers declarations in SENSOR structure.
    4. Invalid #endif syntax.

    HAL4RT_Device.h.patch
    --- org/HAL4RT_Device.h 2016-03-15 03:11:51.496000000 +0900
    +++ mod/HAL4RT_Device.h 2016-03-15 03:14:42.412000000 +0900
    @@ -1,6 +1,7 @@
     #ifndef HAL4RT_DEVICE_H
     #define HAL4RT_DEVICE_H
    
    +#include <stdint.h>
    
     typedef struct HALComponent {
       char ComponentName[32];
    @@ -13,7 +14,7 @@
    
     typedef struct Actuator {
       uint32_t ActuatorKindId;
    -} ACTUATOR
    +} ACTUATOR;
    
    
     typedef struct Sensor {
    @@ -21,13 +22,13 @@
       int32_t ValueOfMeasurement[32];
       int32_t ScaleFactor[32];
       int32_t Origin[32];
    -  int32_t GetSensorKind();
    -  int32_t GetValueOfMeasurement();
    -  int32_t SetUintOfMeasurement();
    -  int32_t GetUnitOfMeasurement();
    -  int32_t SetScaleFactor();
    -  int32_t SetOrigin();
    -} SENSOR
    +  int32_t (*GetSensorKind)();
    +  int32_t (*GetValueOfMeasurement)();
    +  int32_t (*SetUintOfMeasurement)();
    +  int32_t (*GetUnitOfMeasurement)();
    +  int32_t (*SetScaleFactor)();
    +  int32_t (*SetOrigin)();
    +} SENSOR;
    
    
    -#endif HAL4RT_DEVICE_H
    +#endif /* HAL4RT_DEVICE_H */
    
  • Reported: HAL4RT 1.0b1 — Mon, 14 Mar 2016 18:24 GMT
  • Updated: Mon, 6 Nov 2017 12:34 GMT

Inconsistent definition of notify_error(), and return value of "notify_error()" seems not necessary

  • Key: HAL4RT-7
  • Status: open  
  • Source: AIST ( Dr. Noriaki Ando)
  • Summary:

    The definition of notify_error() functions in "ApplicationBase" and "System" are inconsistent.

    p.19, 7.4.3.1, Table 7.4
    notify_error()'s return type is not defined explicitly, but definition of class and interface table in 7.2 describes as follows: "Also, as the type of return code for every operation in this specification is Returncode, which is defined in Section7.3, Return Codes, this is omitted in the description table." Therefore, return type of the notify_error() is ReturnCode from the definition in the table.

    p.19, 7.4.3, Figure 7.6
    ApplicationBase::notify_error() and System::notify_error() in the figure are defined as having no return value.

    p.21, 7.4.3.2, Table 7.7
    Return type of the notify_error() is ReturnCode from the definition in the table.

    p.33, 7.5.2 C PSM
    ApplicationBase::notify_error(), Event::notify_error() are defined as having int32_t type return value.

    Since the notify_error() functions are just callback functions, return value of "notify_error" seems not necessary.

  • Reported: HAL4RT 1.0b1 — Mon, 14 Mar 2016 17:59 GMT
  • Updated: Mon, 6 Nov 2017 12:34 GMT

Inconsistent definition of notify_event(), and return value of "notify_event" seems not necessary

  • Key: HAL4RT-6
  • Status: open  
  • Source: AIST ( Dr. Noriaki Ando)
  • Summary:

    The definition of notify_event() functions in "ApplicationBase" and "Event" are inconsistent.

    p.19, 7.4.3, Figure 7.6
    ApplicationBase::notify_event() is defined as having int type return value.

    p.20, 7.4.3.1, Table 7.6
    notify_event()'s return type is not defined explicitly, but definition of class and interface table in 7.2 describes as follows: "Also, as the type of return code for every operation in this specification is Returncode, which is defined in Section7.3, Return Codes, this is omitted in the description table."
    Therefore, return type of the notify_event() is ReturnCode from the definition in the table.

    p.21, 7.4.3.2, Table 7.7
    Return type of the notify_event() is ReturnCode from the definition in the table.

    p.23, 7.4.5, Figure 7.8
    Event::notify_event() is defined as no retunr value.

    p.33, 7.5.2 C PSM
    ApplicationBase::notify_event(), Event::notify_event() are defined as habing int32_t type return value.

    Since the notify_event() functions are just callback functions, return value of "notify_event" seems not necessary.

  • Reported: HAL4RT 1.0b1 — Mon, 14 Mar 2016 17:36 GMT
  • Updated: Mon, 6 Nov 2017 12:34 GMT

Notation variability of terms: Application Program(ming) Interface

  • Key: HAL4RT-5
  • Status: open  
  • Source: AIST ( Dr. Noriaki Ando)
  • Summary:

    Some notation variability of terms: Application Program(ming) Interface exist.

    p.13,7.1 General
    Specifically, HAL4RT is an API (Application Program Interface) for the layer between on

    p.15, 7.4.1 Overview
    The Surface layer provides standardized API (Application Program Interface) to application software

    p.19, 7.4.3 Surface layer
    The surface layer is the specification of the Application Programming Interface for the

  • Reported: HAL4RT 1.0b1 — Mon, 14 Mar 2016 14:03 GMT
  • Updated: Mon, 6 Nov 2017 12:34 GMT

"HAL4RT components" first appeared without any description in the section 7.4.1

  • Key: HAL4RT-4
  • Status: open  
  • Source: AIST ( Dr. Noriaki Ando)
  • Summary:

    "HAL4RT components" first appeared without any description in the section 7.4.1.
    It would be better add a reference to "7.4.5.1 HAL component."

  • Reported: HAL4RT 1.0b1 — Mon, 14 Mar 2016 13:51 GMT
  • Updated: Mon, 6 Nov 2017 12:34 GMT

Generic error code such as HAL_ERROR is not necessary?

  • Key: HAL4RT-3
  • Status: open  
  • Source: AIST ( Dr. Noriaki Ando)
  • Summary:

    In the section 7.3, table 7.3, six return codes HAL_(OK, NO_CONNECTED, NO_MEMORY, NULL_PARAMETER, NOT_IMPLEMENTED, BAD_PARAMETER) are defined. Error codes is too specific to describe generic erros.

    For example, a device might returns device specific error such as "Invalid initialization error", "Motor is too hot", "Sensor broken" and so on. If device returns these kind of errors, current definition cannot notify these kind of error.

    A generic error code such as HAL_ERROR should be defined for user/device vendor dependent error and/or generic error.

  • Reported: HAL4RT 1.0b1 — Mon, 14 Mar 2016 13:38 GMT
  • Updated: Mon, 6 Nov 2017 12:34 GMT

Difference between HAL_NULL_PARAMETER and HAL_BAD_PARAMETER is ambiguous

  • Key: HAL4RT-2
  • Status: open  
  • Source: AIST ( Dr. Noriaki Ando)
  • Summary:

    In the section 7.3, some return codes are defined.

    The meaning of HAL_NULL_PARAMETER is described as "The parameter is not supported." The meaning of HAL_BAD_PARAMETER is described as "The operation failed because an illegal argument was passed to it."

    The difference between "unsupported parameter" and "illegal arguments" are ambiguous, and usage of return codes are not defined clearly in the following specification description. This definition might confuse implementors.

  • Reported: HAL4RT 1.0b1 — Mon, 14 Mar 2016 13:22 GMT
  • Updated: Mon, 6 Nov 2017 12:33 GMT

Return Code HAL_NO_CONNECTED should be NOT_CONNECTED or NO_CONNECTION

  • Key: HAL4RT-1
  • Status: open  
  • Source: AIST ( Dr. Noriaki Ando)
  • Summary:

    In the section 7.3 Return Codes, the return code type and some return codes are defined in Table 7.3. One of the return code "HAL_NO_CONNECTED" naming is not grammatically correct. It should be "HAL_NO_CONNECTION" or "HAL_NOT_CONNECTED."

  • Reported: HAL4RT 1.0b1 — Mon, 14 Mar 2016 12:59 GMT
  • Updated: Mon, 6 Nov 2017 12:33 GMT