The excel file contains the details for a modified IEEE 30-bus system and the parameters of wind modeling methods.

Instructions: 

The details about the data are provided in the excel sheets.

Categories:
242 Views

The large variability of system and types of heating load is a feature of the commercial metering of thermal energy. Heating consumption depends on many factors, for example, wall and roof material, floors number, system (opened and closed) etc. The daily data from heating meters in the residential buildings are presented in this dataset for comparing the thermal characteristics. These data are supplemented by floors number, wall material and year of construction, as well as data on average daily outdoor temperatures.

Categories:
601 Views

Behavioral traits for 115 employees in public buildings, namely sensitivity to personal comfort loss, desire for conformance to social norms, desire for teaming, desire for rewards. Data has been collected in the pilot studies of H2020 ChArGED for gamified energy conservation in public buildings (grant agreement no. 696170). 

Categories:
159 Views

The dataset comprises raw data to validate methods for reliable data collection. We proposed the data collection methods in a path to assess digital healthcare apps. To validate the methods, we conducted experiments in Amazon Mechanical Turk (MTurk), and then we showed that the methods have a significant meaning based on statistical tests.

Categories:
117 Views

Ropsten Ethereum format is an “Ethereum Testnet” that runs the same protocol as Ethereum.

It contains the following fileds:

 

-Transaction Hash code

-Block Number

-Unix Timestamp

-Date and Time

-Adress From

-Adress To

-Contract Adress

-Value In (in Ethereum)

-Value Out (in Ethereum)

-CurrentValue

-Transfer Fee (in Ethereum)

Instructions: 

EXPERIMENT RESULTS, EVALUATION AND DISCUSSION

The experimental prototype of the proposed remitance model was evaluated over two days from May 22 to May 23, 2019, each day from 9 am to 4 am GMT+1 using the experimental prototype. 160 remittance transactions were performed. All the transactions details are publicly available on the Ropsten public log available at: https://ropsten.etherscan.io/address/0x904248FE328a186CE76666ee9e2548Ab2.... On the day of the transactions, the value of one Ether was $230.17 USD.

 

The proposed model was evaluated in regard to 2 criterions. The first was to ensure that the entire process behaved in a trustworthy manner in regard to the intention of the expeditor and the second examined the financial cost of using the system compared to actual MTO services.

 

To test the trustworthiness of the model, different scenarios were tested to ensure that the logic embedded in the application prototype behaved as expected. These test scenarios were simulated using Selenium, a Web automation framework. Selenium simulates human interaction using a web based application. With Selenium, one can track every key stroke a user enters in the system, and at each step check the internal state of the system. Testing using Selenium not only allows us to test the quality of the code, but it also tests the overall behavior of the system as seen by the end user, especially the page responsiveness.

 

The prototype was tested for 80 different scenarios. For each scenario, the test result was either pass or fail. The tests included security scenarios where the most common attacks were simulated, and the normal functioning of the application with scenarios simulating participants not sending confirmation on time, or sending wrong signatures, or participants trying to cheat or hack the system. The tests targeted the application layer, which interacts with the end users, as well as the smart contract logic layer.

 

After the correction of all the coding defects, the second version of the prototype was submitted to all the tests and behaved according to our proposed definition of a trustworthy remittance system. However, an important caveat should be noted. Scenarios not considered in this first research activity could exist that would show the model may not perform as intended, especially in the logic layer dealing with the smart contract reliability. Testing smart contract reliability is an important area of research. 

 

To determine how costly the use of the proposed trusted remittance application would be compared to a current MTO, the prototype was tested using Ropsten, the public Ethereum test network. Ropsten is the closest system to the real Ethereum network. Using Ropsten allows us to have a close approximation of how the system would behave in real life.  

 

When we discuss the cost of using the proposed model, we refer to the gas cost, which is the cost charged by the Ethereum network to perform a transaction. With Ethereum there are no free operations; every operation (command) performed in the system costs Ether and it is identified as a gas fee. This gas fee can be understood as a constraint to oblige the developer of a smart contract to use the least resource intensive operation possible. The gas fees are distributed to miners of the Ethereum network as compensation for maintaining security. 

 

In a commercial sense, in addition to the gas fees that are collected by the network, the operator of the smart contract should also set its own fees. For this experimentation, this remittance fee was set to zero and only the cost of using the Ethereum resource network has been studied.   

 

160 transactions were performed on the Ropsten network. A transaction was comprised of the 3 stages of a remittance of service: the expeditor sending money through the system, confirmation of the transaction by the service provider and the beneficiary, and transferring the money to the service provider or to the expeditor in the case of a failed transaction.

Table 4 shows the average cost for each step of the transaction was between 3.08 Ether to 0.3 Ether. The total average cost of a remittance transaction is $1.29, irrespective of the amount remitted. This is largely below the $15 that is usually paid for a remittance of $200 sent from Canada to the DRC using Western Union. If we consider that this amount is only the cost of using the system and does not take into account any fee for the (RS) operator, adding a small overhead charge for the (RS) operator would still make the system commercially competitive compared to an MTO.

 

            Table 4: Cost of using the application

Actor

Operation

Average cost in USD

Expeditor

 

 

 

Transferring money

0,6608527 $

Beneficiary

 

 

 

Signing Confirmation 

0,21955631 $

 

Choosing a service provider

0,20657076 $

Service provider

 

 

 

Signing confirmation

0,20657076 $

Total cost of the transaction

 

1,29355053$4

 

 

 

 

 

 

 

 

 

 

 

 

 

Results show that amount remitted has no influence on the cost of the transfer, the gas cost charged by the Ethereum network. It seems that there is a slight dependence between the time a transaction is completed and the gas cost, however. This could be linked to the load of the system at certain time of the day.

 

The time to complete a command in the Ethereum network, whether sending money or confirming a transaction, ranged from 5s to 1 minute during the testing. It has been observed that this time is a function of the network load and is not related to the amount or type of the command.

 

It was also noted that when using Ethereum, the cost of the transaction is spread among the participants. In the current MTO model, the expeditor bears all the costs of the transaction. In the proposed remittance of service model using Ethereum, each participant has to pay a fee. 

 

This is mandatory due to the manner in which Ethereum works. With Ethereum there are no free transactions; every command executed in the Ethereum network costs a transaction fee. This could be addressed in a future iteration of the system model with a functionality computing the expected gas cost to be paid by each participant and incorporating it in the expeditor fees. In this manner, the system will reimburse automatically gas fees to the other participants.

Categories:
684 Views

800x600

Normal
0

false
false
false

EN-NZ
X-NONE
AR-SA

MicrosoftInternetExplorer4

Categories:
95 Views

Data of our paper, Expansion Coding for Performance and Lifetime Improvement on MLC STT-RAM.

Categories:
32 Views

Data are used for the paper titled "Box-Office Forecasting Using the Random Forest Algorithm: Evidence from the Taiwanese Film Market"

 

 

   

Categories:
105 Views

A set of datasets (Excel files since it also contains dynamically generated images) to facilitate the reproducibity of the test performed for the evaluation of the FDS proposal

Instructions: 

Description: The set of datasets used for the paper in order to get the graphics that summarize the results from these datasets.Size: 293 KBPlatform: Microsoft Excel 365Environment: Any running MS Excel (Linux, Windows, MacOS)Major Component Description: 3 files are provided, each corresponding to a different dataset(s) with several sheet.1. "Comm latency": contains datasets and figures related with the data obtained when evaluating the communication latency of the proposal and the Amazon Cloud service one.    · "Measures FDS": sheet that contain the data obtained when evaluating the communication latency of the proposal (FDS)    · "Measures Cloud": sheet that contain the data obtained when evaluating the communication latency of Amazon Cloud service    · "Comparison": a sheet containing a dynamic figure for comparing the data of the other two sheets2. "Power consumption": the largest dataset. It contains the samples for different situations regarding power consumption in the sensor nodes when using FDS or when running as they normally do (without storing any kind of data)    ·Idle (DTIM1) naked 3,3V: sheet contains the samples for the "base" power consumption of a "bare-mounted" ESP8266 avoiding a programmer IC and a voltage regulator. Constant current was provided using an external power generator    ·TX no SD card: sheet contains the power consumption data while transmitting when FDS is not used (no SD data storage is performed)    ·RX no SD card: sheet contains the power consumption data while receiving when FDS is not used (no SD data storage is performed)    ·RXTX no SD card: sheet contains the power consumption data while transmitting and receiving when FDS is not used (no SD data storage is performed)    ·TX with SD card: sheet contains the power consumption data while transmitting when FDS is used (SD data storage is performed)    ·RX with SD card: sheet contains the power consumption data while receiving when FDS is used (SD data storage is performed)    ·RXTX with SD card: sheet contains the power consumption data while transmitting and receiving when FDS is used (SD data storage is performed)        ·Comparison: sheet including the dynamic figure generated from the other sheets3. "Network overload": contains datasets and figures related with the data obtained when evaluating the network overload of the proposal and the Amazon Cloud service one (best and worst scenario).    · Received: sheet contains number of messages for different replicates configuration in FDS as well as counts for the number of messages for the best and worst case for Amazon regarding messages received.    · Sent: sheet contains number of messages for different replicates configuration in FDS regarding messages sent.Detailed Set-up Instructions: Unzip and open the files with MS ExcelContact Information: for additional information about these datasets, contact Marino Linaje, the corresponding author (mlinaje@unex.es)

Categories:
102 Views

These data are collected from a 12-bus and a 32-bus DC microgrid. The total operating cost of these two microgrids are optimized by an adaptive Differential Evolution algorithm using real-time pricing.

Categories:
313 Views

Pages