I want to learn how to use diagnostic operation cycle block in Autosar Blockset.
this block consist of two operation, SetOperationCycleState and GetOperationCycleState.
To set an operation cycle state the Simulink defines a prebuilt enumeration called Dem_OperationCycleStateType, but I can not find any information about this type in AR documentation.
Any help would be greatly appreciated
It depends on the AUTOSAR Version you are looking at. It seems in AUTOSAR 4.4.0, the interfaces Dem_SetOperationCycleState() / Dem_GetOperationCycleState() are replaced by Dem_RestartOperationCycle(). And this new interface does not need a state argument.
In AUTOSAR 4.3.1, the definition is chapter 8.6.1.15
Dem_OperationCycleStateType
[SWS_Dem_00929] Dem_OperationCycleStateType
Type: Derived from uint8
Description: This type contains operation cycle state values, which can be reported via Dem_SetOperationCycleState()/
Dem_GetOperationCycleState().
Range:
DEM_CYCLE_STATE_START - 0x00 - Start/restart the operation
cycle
DEM_CYCLE_STATE_END - 0x01 - End the operation cyclein
Related
Issue
When using pydnp3 master station to query data from outstation, the measurement value can only print out at terminal, and there is no public interface method to retrieve measurement value in a clean way. i.e., the ScanRange method returns None (instead of the measurement value.)
Observations
Note that the version used to bind pydnp3 0.1.0 is outdated (2019).
The pydnp3 author seems to know that there is no measurement-retrieval entry point.
img1
The object that handle measurement processing (one kind of SOE) seems to be SOEHandler. However, there seems to one SOEHandler available and it only print measurement to the terminal(console.) Note: PrintingSOEHandler class is a binding from c++ binary. (i.e., __pydnp3_opendnp3.ISOEHandler)
img2
img3
Potential solution and core issue
rebind opendnp3, But how?
Suppose that I have a program that takes a pointer as its input. Without prior knowledge about the structure of the pointee, how does a fuzzer create valid inputs that can actually hits the internal of the program? To make this more concrete, imagine an artificial C program
int myprogram (unknow_pointer* input){
printf("%s", input->name);
}
In some situations, the tested program first checks the input format. If the input format is not good, it raises an exception. In such situations, how can a fuzzer reach program points beyond that exception-raising statement?
Most fuzzers don't know anything about the internal structure of the program. Different fuzzers dealt with this in a various ways:
Not deal with it at all. Just throw random inputs and hope to produce an input that will pass some/all checks. (for example - radamasa)
Mutate a valid input - take a known valid input, and mutate it (flip bits, remove parts, add parts, etc.) in many cases it will be valid enough to pass some or all of the checks. For example - if you want to fuzz VLC, you will take a valid movie file as the input for the fuzzer, which will provide mutations of it to VLC. Those are often called mutation based fuzzers. (for example - zzuf)
If you have prior knowledge of the input's structure, build a model of the input, and then mutate specific fields within it. A big advantage of such method is the ability to deal with very specific types of fields - checksums, hashes, sizes, etc. Those are often called generation based fuzzers. (for example - spike, sulley and their successors, peach)
However, in recent years a new kind of fuzzers was evolved - feedback based fuzzers - these fuzzers perform mutations on a valid (or not) input, and based on feedback they receive from the fuzzed program they decide how and what to mutate next. The feedback is received by instrumenting the program execution, either by injection tracing in compile time, injecting the tracing code by patching the program in runtime, or using hardware tracing mechanisms. First among them is AFL (you can read more about it here).
A fuzzer throws every sort of random combination of inputs at the attack surface. The intention is to look for any opportunity for a "golden BB" to get past the input checks and get a response that can be further explored.
I am reading the book "Computer Organization and Embedded Systems" by Hamacher and my question is: "How does a computer distinguish whether a binary pattern is an instruction or just a number?"
Can anyone help me understand that concept?
A Von Neumann Processor (pretty much any processor out there) can not distinguish between code and data in memory. What ever the instruction pointer of the CPU points to will be loaded into the instruction decoder as an instruction. If it is not a valid instruction it will raise an exception in the CPU.
This enables a program to create new executable code in memory or even change its own code. On the other hand this enables many code injection attacks.
The way the computer distinguishes between instructions and numbers simply depends on what is reading the data and where. For example, a simple Arithmetic Logic Unit (ALU) will include an input for the operation to be done, and two inputs for the operands. The data going into the operand ports is read as numbers, whereas the data going into the operator input is read as an instruction.
It all depends on what computer architecture unit is reading the data, and on what input that unit is reading it.
I've been reading through this section for a while, but I can't seem to figure it out. I'm on AMD64 ABI Draft 0.99.6, page 18, section 3.32 Parameter Passing and theres the following text:
Arguments of type __m256 are split into four eightbyte chunks. The least significant one belongs to class SSE and all the others to class SSEUP.
I'm confused because it sounds like I use three SSEUP registers and only one SSE, but that seems wasteful of the other two SSE registers associated with the SSEUP. Am I misreading it? I probably won't even use this datatype, but I've been confused on this text for quite a while. Can someone give an example of how this would work? I'm probably missing something obvious.
Page 18 just contains a list of definitions necessary for a later discussion of the algorithm used to pass the parameters of a function.
Particularly, the SSE class is always passed in a new vector register, the first available of %xmm0-%xmm7.
Note that these names refer to the lower 128-bit parts of the registers but its better to think of them in terms of variable size vector registers %v0-%v7.
The SSEUP class is passed in the next available 64-bit (eight-byte) of the last vector register used.
__m256 is then passed, in processors that support AVX, using a single %ymm register: the lower 64 bits get the SSE class - and hence a new %v0 register - while the other three 64 bits chunks get SSEUP thereby reusing the %v0 register.
Here's the relevant quote from the document:
If the class is SSE, the next available vector register is used, the registers
are taken in the order from %xmm0 to %xmm7.
If the class is SSEUP, the eightbyte is passed in the next available eightbyte
chunk of the last used vector register.
The SSEUP class was introduced earlier in the ABI and it is still present today.
You can quickly consult the Version 0.9 to see the differences: the type _m256 and _m512 were not present for example.
For compiler that doesn't support the new ABI with the _m256 type or for compilers that do support it but target processors with no AVX support, that type is usually an aggregate of two _m128 and thus by the rules described later (particularly the post-merge rules) it is passed in memory:
If the size of an object is larger than two eightbytes, or in C++, is a nonPOD structure or union type, or contains unaligned fields, it has class
MEMORY.
For compilers using the old ABI
If the size of the aggregate exceeds two eightbytes and the first eightbyte
isn’t SSE or any other eightbyte isn’t SSEUP, the whole argument
is passed in memory.
For compilers using the new ABI
The standard is admittedly confusing mostly due to the need to address backward compatibility, the SSE and SSEUP classifications are handy classifications in an architecture where the vector registers keep widening and broad range of different sizes are already present out there.
in UVM e Reference document is written:
You can call read_reg_field or write_reg_field for registers whose fields
are defined as single_field_access (see “vr_ad_port_unit Syntax and Examples”).
...
For example:
write_reg_fields tx_mode_reg {.resv = 4; .dest = 2};
But there is no example for using read_reg_field...
Could you please explain how should it be used?
(I've tried the next code, but it gives compilation error:
some_var = read_reg_field my_reg_file.my_reg {.my_reg_field} )
Thank you for your help.
As far as I know there is no read_reg_fieds macro. If you want to do a read to a register and then save the value of a certain field, do this:
read_reg my_reg;
value = my_reg.my_reg_field;
Normally, when you read register, you read them completely. Reading only individual fields makes sense if your bus protocol allows narrow transfers (i.e. your data width is 32 bits, but you can do 16 bit transfers on it). I haven't seen such a thing implemented in vr_ad (could be there and I just don't know of it), but UVM RAL (the SystemVerilog register package) supports it.
Long story short, if you just care about getting your data from your DUT, using read_reg is enough.
When the Design Under Test is implemented in verilog or vhdl - you can read the register as a whole, you cannot "read just some of its fields".
A register is at a specific address, reading this register -> read from this address.
The quote of the spec about fields access is when the DUT is a SystemC model.
Connecting to SC models is done using ports. If the model defines a port for each field - you can read a field.