• Journal of KIISE:Computing Practices and Letters
• /
• v.9 no.4
• /
• pp.393-409
• /
• 2003

In this paper, we present a multi-task debugging environment for Qplus-T embedded-system such as internet information appliances. We will propose the structure and functions of a remote multi-task debugging environment supporting environment effective ross-development. And, we are going enhance the communication architecture between the host and target system to provide more efficient cross-development environment. The remote development toolset called Q+Esto consists to several independent support tools: an interactive shell, a remote debugger, a resource monitor, a target manager and a debug agent. Excepting a debug agent, all these support tools reside on the host systems. Using the remote multi-task debugger on the host, the developer can spawn and debug tasks on the target run-time system. It can also be attached to already-running tasks spawned from the application or from interactive shell. Application code can be viewed as C/C++ source, or as assembly-level code. It incorporates a variety of display windows for source, registers, local/global variables, stack frame, memory, event traces and so on. The target manager implements common functions that are shared by Q+Esto tools, e.g., the host-target communication, object file loading, and management of target-resident host tool´s memory pool and target system´s symbol-table, and so on. These functions are called OPEn C APIs and they greatly improve the extensibility of the Q+Esto Toolset. The Q+Esto target manager is responsible for communicating between host and target system. Also, there exist a counterpart on the target system communicating with the host target manager, which is called debug agent. Debug agent is a daemon task on real-time operating systems in the target system. It gets debugging requests from the host tools including debugger via target manager, interprets the requests, executes them and sends the results to the host.

• KIPS Transactions on Software and Data Engineering
• /
• v.1 no.1
• /
• pp.19-30
• /
• 2012

The context aware service is the service to provide useful information to the users by recognizing surroundings around people who receive the service via computer based on computing and communication, and by conducting self-decision. But CAS(Context Awareness System) shows the weak point of small-scale context awareness processing capacity due to restricted mobile function under the current mobile environment, memory space, and inference cost increment. In this paper, we propose a mobile cloud context system with using Google App Engine based on PaaS(Platform as a Service) in order to get context service in various mobile devices without any subordination to any specific platform. Inference design method of the proposed system makes use of knowledge-based framework with semantic inference that is presented by SWRL rule and OWL ontology and Jess with rule-based inference engine. As well as, it is intended to shorten the context service reasoning time with mapping the regular reasoning of SWRL to Jess reasoning engine by connecting the values such as Class, Property and Individual which are regular information in the form of SWRL to Jess reasoning engine via JessTab plug-in in order to overcome the demerit of queries reasoning method of SparQL in semantic search which is a previous reasoning method.

• Journal of KIISE
• /
• v.43 no.1
• /
• pp.87-95
• /
• 2016

Recently, due to the development of the Internet and electronic devices, there has been an enormous increase in the amount of available knowledge and information. As this growth has proceeded, studies on large-scale ontological reasoning have been actively carried out. In general, a machine learning program or knowledge engineer measures and provides a degree of confidence for each triple in a large ontology. Yet, the collected ontology data contains specific uncertainty and reasoning such data can cause vagueness in reasoning results. In order to solve the uncertainty issue, we propose an RDFS reasoning approach that utilizes confidence values indicating degrees of uncertainty in the collected data. Unlike conventional reasoning approaches that have not taken into account data uncertainty, by using the in-memory based cluster computing framework Spark, our approach computes confidence values in the data inferred through RDFS-based reasoning by applying methods for uncertainty estimating. As a result, the computed confidence values represent the uncertainty in the inferred data. To evaluate our approach, ontology reasoning was carried out over the LUBM standard benchmark data set with addition arbitrary confidence values to ontology triples. Experimental results indicated that the proposed system is capable of running over the largest data set LUBM3000 in 1179 seconds inferring 350K triples.

• KIISE Transactions on Computing Practices
• /
• v.21 no.8
• /
• pp.524-530
• /
• 2015

A log is for text monitoring and perceiving the issues of a system during the development and operation of a program. Based on the log, system developers and operators can trace the cause of an issue. In the development phase, it is relatively simple for a log to be traced while there are only a small number of personnel uses of a system such as developers and testers. However, it is the difficult to trace a log when many people can use the system in the operation phase. In major cases, because a log cannot be tracked, even tracing is dropped. This study proposed a simplified tracing of a log during the system operation. Thus, the purpose is to create a log on the run time based on an ID/IP, using features provided by the Logback. It saves an ID/IP of the tracking user on a DB, and loads the user's ID/IP onto the memory to trace once WAS starts running. Before the online service operates, an Interceptor is executed to decide whether to load a log file, and then it generates the service requested by a certain user in a separate log file. The load is insignificant since the arithmetic operation occurs in a JVM, although every service must pass through the Interceptor to be executed.